[*Unresolved* Issue] Alienware M18x: GTX 580M SLI DPC Latency Problems

i have the same scenario, what i did is i made an individual customized shortcuts on nspector, 400/400 for p8 and p12 using the 'unlock max' option, still even after applying so, when i do a recheck and reopen nspector i would get the default values on p8 and p12. is it possible to set 400 on default on those values given that we had to unlock the max clock value on p8 and p12?

im not sure if i do it correctly or if i missed something, but the shortcuts that i made p0 and p1 in the first fox fix works.

@Mr fox, how did you get the 400 values to run default on start up?

 

I have attached the batch file that I have in my startup folder and it is working perfectly every time. I will compare the content to make sure there is no typo in what I posted before.

If you are making your own shortcuts, you have to click the "Apply Clocks & Voltage" button in NVIDIA Inspector before creating any shortcuts. You need to have a shortcut for each power state and each video card, so that means 8 shortcuts in our SLI setups (which is why it is better to use a batch file). These settings will not stay as the defaults when you launch Inspector unless the clock speeds are already running at the same speed. In other words, if you have not launched the batch file or shortcuts and your cards are running at factory default speeds for P8 and P12, that is what you will see showing in NVIDIA Inspector. The settings are not persistent in Inspector after rebooting, which is why you need to create a batch file or individual shortcuts. If you have not already launched your batch file you will see P12 at 50/135/101 when you launch Inspector. That is the vBIOS default that is hard-coded. If you have Inspector open and then launch the patch file, you should see P8 and P12 for both cards change to 400/400 right before your eyes.

You do not need to create 8 shortcuts for NVIDIA Inspector if you use the correct commands in the batch file. In fact, there is no need to ever open or launch NVIDIA Inspector if you have the correct commands in the batch file.

The way I made the batch file was to create shortcuts for each P-state for each card. Then I copied and pasted the commands from the shortcuts into the batch file as text. In addition to attaching my own batch file, I have attached some screen shots. Because my batch file launched at start up, when I open NVIDIA Inspector and go to P8 or P12, my settings are already showing 400/400 without any adjustment, just exactly as you see in the attached screen shots.

Hope this helps, guys. My guess is there is a typo or something in the batch file you are using. Otherwise, I am stumped. The batch file is working flawlessly for me.

Spoiler

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:0,0,400 -setMemoryClock:0,0,400

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:0,1,400 -setMemoryClock:0,1,400

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:1,0,400 -setMemoryClock:1,0,400

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:1,1,400 -setMemoryClock:1,1,400

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:0,2,1240 -setMemoryClock:0,2,1500

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:1,2,1240 -setMemoryClock:1,2,1500

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:0,3,1240 -setMemoryClock:0,3,1500

start D:\nvidiaInspector\nvidiaInspector.exe -setShaderClock:1,3,1240 -setMemoryClock:1,3,1500

Steve asked me about the voltage part of the batch file commands and this is not a necessary part of the command syntax. In fact, adding voltage parameters has no effect at all because voltage on the GTX 580M cannot be changed by using NVIDIA Inspector.

Edit: Just a thought. Probably has no merit, but I don't want to assume anything. Be sure you are not using two batch files in your startup folder. The one attached includes the throttling fix and the DPC latency fix. If you are launching multiple shortcuts or batch files they might be canceling out what you are trying to accomplish.

 

thanks for clarifying mr. fox, i chose the shortcuts coz running the batch files gives me some cmd problems, anyways i applied the settings before making shortcuts and now after 2 startups its working.

+1 rep!

 

Thank you for the rep. Glad you got things working.

You may not be getting an elevated command prompt, and that may be why the settings do not consistently take effect using a batch file. I believe the commands must be executed with administrator rights.

I have UAC (user account control) totally disabled on my system and everything I do is with elevated Administrator privileges. I am never prompted to approve anything, ever. (If I tell my computer to do something, once is enough for me. If I have to tell it twice or repeat myself, we're going to be having big problems. Just like my kids, LOL.)

 

I am having problems thinking that this issue is actually resolved. I have been getting spikes/high readings ever since enabling SLI. I am using Fox's clocks for all P states (got it working properly upon rebooting now LOL) and obvioulsy the latest Nvidia drivers. I also updated the latest version of PhysX Software too.

After [revious testing, I thought that I might have had a bad install so I have redownloaded and reinstalled the whole driver set again....still no dice. She aint playin' nice!

LatencyMon is STILL showing the Nvidia Driver spiking high enough to give the message that "your system has difficulty in handling audio etc etc - you may experience pops/clicks and/or dropouts"

Very disconcerting - I am wondering for those of you who arent having any problems, what EXACTLY you have done different or have implemented for latency to be completely resolved?

See the spoiler:

Spoiler

Another poor latency result - this time with triple buffering enabled in NVCP.

Spoiler

 

The only thing I did differently, at least that I know of, it disabled my Atheros NIC in Device Manager. I only use wireless LAN. But, I did that after resolving the NVIDIA DPC latency.

I thought you ran for 3 hours without a spike the other day. Not sure why it has changed. Try setting everything back to defaults in NVIDIA Control Panel.

 

Well, yeah I did run x3 hour long tests - each came back fine - until I realised I had been testing with SLI disabled after installing the new WHQL Driver (forgot to enable it - D'oh!)

Consequently, testing since has been with SLI enabled. I have just but han hour or so ago, uninstalled and reinstalled the Nvidia Driver - everything is stock settings (with the exception of triple buffering - gunner's recommendation a page back I think) in Nvidia Control Panel.

Using your .bat (after my difficulty in getting it to execute 100% of the time - likely to have been my raided ssd's like we discussed) too, but still spiking.

Guess I could always give the Atheros trick a whirl but I really dont think it can be called "fixed" if you have to disable a bunch of stuff to get it working without latency, right?

 

The network DPC latency with the Atheros NIC or using the wrong Killer Wireless drivers is unrelated to the NVIDIA DPC latency.

Try this. Get rid of your startup shortcuts. Go to All Programs > Accessories > System Tool and launch Task Scheduler. Create a new task and point the task to your batch file. Tell it to run at log-on. I am testing this now and it works great. Maybe it will work well for you also.

 

OK. Done that - the task starts up nicely - sets P states correctly so far....will re-run LatencyMon.

Side note: When you have been testing for Latency, what have you been doing Bro? - have you had music playing in the background and browser open or have you just been idling along with nothing?

Ok, thats a fail too.......

Spoiler

 

Cool! Glad to hear that the Task is working smoothly.

With respect to your question... No, I am not running anything in the background. I also have SLI enabled. I think that you're supposed to test for DPC latency at idle without any background applications running. Maybe that is why your test results are not good. Try testing with nothing playing.

Notwithstanding the test results, are you hearing any clicks and pops or buzzing noises while playing music. Or, if you rip an MP3 audio or MP4 video file, are you getting any audio or video glitches with the new drivers? If you are not and everything is looks and sounds good, then it's kind of moot what LatencyMon is reporting. It only matters if you have symptoms that are problematic.

For many of us, before NVIDIA released the new driver and before I came up with the idea of bumping up P8/P12 clocks, the DPC latency was causing no problems. I was not having any serious symptoms that I knew about, but I don't do the kind of editing that 'gunner does. If push comes to shove and temporarily having SLI turned off while doing audio/video editing, that may be something we have to contend with until NVIDIA takes their driver quality to the next level and fixes it with SLI turned on (for everyone). It would be better for some users to have to temporarily turn off SLI to do their editing than to have a single GPU and not have the advantage of SLI being available for gaming when needed.

It's just odd that it's different for some users, but we have slightly different hardware configurations as well. Different CPU, different RAM, different wireless cards, and all of these drivers have to play nice together. Again, this goes back to the way Microsoft designed Windows Vista and Windows 7 to handle multimedia synchronously in user mode instead asynchronous kernel mode. This makes Windows stable and keeps crashing to a minimum. This makes driver development more complex because driver A has to be kind to driver B and not "steal the show" so to speak. Even differences in BIOS settings can cause differences in DPC latency. I am running at 44x on all cores @ 100.0Mhz with C states disabled. My DPC latency might go up or down if I were to choose different CPU frequency settings. This makes driver development more complex as well, since there is no such thing as a "level playing field" or baseline configuration. You may have also noticed that DX11 is causing high ISR routine execution, which can cause spikes in DPC latency.

Edit #1: another thing to try, with SLI enabled, is to tell NVIDIA Control Panel to "Use the Advanced 3D Image Settings" and be sure that your Global profile has "Prefer Maximum Performance" as the Power Management Mode (not Adaptive). These are the settings I am running.


Edit #2: Just for the purpose of comparison, running music in the background with SLI enabled, I still have no DPC latency. See below.

Spoiler

 

Thanks for the great response Bro. I actually think I solved it just before reading your post. Although I have not been hearing dramatic pops/clicks etc, I still hated the thought that my system was giving higher readings that what it *should* be doing, compared to others. (if something is shown to be working correctly, I expect it of myself to attain the same results and it was bugging the heck outta me!)

I didnt know that regarding testing for DPC Latency, it should be done whilst idling - I might be wrong but I thought the whole point of it was to ensure that we DONT have pops or clicks whilst playback/editing - so in my mind, what better way to put it to the test than by playing some music etc and see how she holds up.....just my way of looking at things.

So, how did I get it working properly you are wondering now, right? LOL - well, I tried allsorts as you know but what finally made a difference for me (and how bizarre that it should) was regarding LatencyMon itself.

I have a penchant for uninstalling and reinstalling if I think there is the slightest chance its corrupted - not to say it was but I did it anyway. What I did wasnt hugely different to what I had done before but the results changed quite dramtically from previous and I only changed a few things - so it had to be one or both of my changes.

Instead of saving the LatencyMon file and then executing, I ran it from location and also during installation, I chose NOT to have a desktop shortcut. I had been running the LatencyMon via a shortcut previously but this time, I chose to run from its location on my C: Drive.

I also disabled "3d Vision" in the start menu (as you can see below) - wether that made a difference is unknown but I could re-enable it and re-run which would rule that out as a cause.

Other than those "changes", everything else was left as was. I did schedule the .bat to run as a windows task, I chose run at startup opposed to upon login as that actually seemed to work better for me - so far anyway. It sets the P-States nicely to the clocks of your Latency fix .bat. (I will keep an eye on it to see if that changes but looking good so far).

I had triple buffering enabled too but that was the only NVCP "tweak" made.

I plan on running some more tests to see if it was a random fluke but below is a good result. The test was ran for just under 1hr 30mins (dont know why the clock doesnt count up the hours, it just zero's itself after 1hr!). Music was playing the whole time and browser open too, just like my prior testing.

SLI was, of course, enabled THIS TIME........what a donut I was missing that one.....

Check it out - max reading from the NV driver was under 500us the whole 1hr30.....I am hoping it stays that way now!

 

All great info and good ideas you tried, Steve. Very happy it seems to be sorted.

One thing you did that perhaps made a difference is disabling 3D vision. I had not even thought about that as being a difference between systems until you mentioned disabling it.

I do not have 3D vision installed on my M18x. I unchecked it before installing the drivers because I have no use for 3D vision. I don't have a 3D-capable display and have no plans to own one in the immediate future. Considering the 3D overlay error that is unresolved, I saw even less incentive to allow that to be installed and just thought it best to skip that part of the package altogether.

 

Well, just a bit more info.

After restarting a few times, its aparent that even setting the .bat to run either at startup or login results in inconsitent P-State launches for me. Wether my raid ssd's just skip a beat beacuse they are too fast (LOL) is the problem, I dont know but I have tried all options to get the .bat to launch 100% of the time with ALL clocks in force and the only way for ME to do it is by putting several shortcuts in the startup folder. Shouldnt do any harm but thats the only way I can get it to run automatically at the correct clocks as per Mr. Fox's Latency .bat fix.

I have run several tests at idle (without music or browser) and the LatencyMon test passes without a hitch. It slightly concerns me that it doesnt when music is played because I thought a true test of how well a system would handle latency is whilst actually doing the task that would potentially cause the problem of high latency readings...ie playing music etc.....(you cant have pops or clicks if you have nothing running in the background as there is no source to pop & click, if you like)

I wonder how you guys would fair running the tests like I have? - try running LatencyMon for as long as you can with music playing and see when it craps out.....for me, its more or less a foregone concluison that at some point,, it does. Although i have had tests complete for over an hour without issue, I can run the same test without altering anything and the test fails.

It normally fails within 30 mins so it shouldnt take too long for someone to try it out.....maybe just to see if its just my system that cant pass the test 100% of the time whislt running LatencyMon with music/browser open too........

 

It would be good to see more tests... Just thinking out loud here and looking for comments... I am wondering how realistic it is to expect 30 minutes or longer without any kind of DPC spike to occur. I have not tested DPC latency on any system before we started playing with it recently on the M18x in this thread, so I have no past experience to draw from on this subject. It would be interesting to see how other systems fare, and if there are eventually DPC spikes at 30 or 40 or 60 minutes on all systems. I don't really know what to expect as typical behavior.

I only mention this because it may not be something that we should be overly worried about if it is "normal" to eventually, given enough time and stuff happening in the background, see a spike. Thoughts, team?

At the very least, we can be happy that using the P8/P12 tweak and/or the latest NVIDIA Verde WHQL driver brings about massive improvements. LatencyMon goes through the roof almost instantly with out at least one of these in place, using all but the obsolete Dell approved driver and the latest reference driver. Great progress with the tweak and the new driver.

 

I agree. Basically, what I am seeing is whilst using LatencyMon, coupled with either an open browser or say, Windows Media Player running, I get return results from LatencyMon that my system is having problems.....to me that suggests it is indeed not capable of keeping latency low whilst running the very tasks that benefit from low latency to run effectively without issue.

I dont know if we should be expecting zero spikes - I doubt it but I would expect that the system should pass the test without the message that it is incapable of doing so without problems.....especially only after a relatively short period of time.

Just made a rather odd discovery. If I have latencyMon AND Latency Checker running at the same time......all remains good. You can see the figures. Weird. Normally, by this time with just LatencyMon, it would have spiked and crapped out whilst music is playing, switching tabs etc....heck, I even uploaded the shot and its still all good......weird!

Spoiler

 

That is a strange discovery, Steve. Thanks for sharing that. I have noticed that LatencyMon is sometimes the app producing the highest DPC routine execution. I thought it was humorous that a latency checker would cause latency.

I also did more testing this evening and I think I am ready to put this issue to rest for now and consider it a done deal for me.

I disabled page file and rebooted to see what, in any, change I might see. It seems that doing so made no difference in the hard page faults appearing in LatencyMon. It also did not increase or decrease DPC latency.

I ran music and simultaneously looped a video clip for 45 minutes without a spike in DPC latency. As a side note, I would actually expect this because running video causes our GPU clocks to ramp up into performance mode, which prevents DPC latency. As demonstrated by the Fox Fix, increasing GPU core, memory and shader clocks on P8 and P12 prevents DPC latency, so it stands to reason that running video footage that moves the cards to P0 would likewise prevent DPC latency.


After running video and music for 45 minutes, I closed the video and allowed LatencyMon to finish out the hour playing music only with the GPUs clocking down naturally to 200/400/400. Opening and closing apps and windows while playing music and video did not cause a DPC latency spike.


After all that, I decided to look at what some of our common utilities can do to DPC latency. I launched HWiNFO64 and restarted LatencyMon. No problems to report.


I shut down HWiNFO64, launched SpeedFan, restarted LatencyMon and DPC latency was absolutely horrid. Worse than anything I have seen before. (Brother johnkss also documented this in another thread.)


I shut down SpeedFan, launched ThrottleStop, restarted LatencyMon and there was no issue with DPC latency.

 

Haha - I noticed Resplendance pop up too as a cause....that gave me a good laugh!

Thank you for your extensive testing Bro, it certainly does appear you have the DPC beast very well tamed. I am hoping mine stays the same. I took some of your points on board from the previous page and made those changes to the NVCP settings. I will obviously keep an eye on things but on the whole, it seems pretty damnn good.

I wondered wether the pagefile would effect the hardpage faults - again, your testing proves it does not. Saved me a job. Seems like the only real benefit of turning pagefile off would be to return the SSD user a few valuable gb's of space, as there are no SSD performance gainst to be had from it.

I also wondered about the accuracy of latencyMon over that of Latency Checker - using the latter app, I get no spikes at all but in the same test scenario, with the former, I do get spiking occasionally.

Anyway, DPC isnt causing me an issue, I just wanted to get "all green" all the time from my testing....it may not (probably wont) ever happen but we shall see.....

Again, thanks for your help Bro - much appreciated + 1 rep....oops: (I owe ya buddy!)

 

Thanks, Brother Steve. Glad to assist. It helps everyone and you contributed a ton as well.

 

Thanks Mr. Fox....

There is only one thing left nagging in the back of my mind.....after doing some more messing about (just for the sake of it) it seems to me that having IE9 open causes random DPC spiking. I cant nail it down, but I have eliminated having IE9 open whilst testing and all comes back good no matter what - wether I have music playing or a video, the test passes.

Now, if I open IE9 and rerun, thats what causes the random fail results at some point...sometimes it can be 5 mins, sometimes 50mins but at some point it does fail. I havent had a fail result whilst I have been testing without IE9 open......

Go figure.....

 

That is very interesting. I use almost exclusively Google Chrome with IE9 as backup only for web pages that cannot display correctly in Chrome (which is very rare). That may explain why I experienced no spikes. There is an element of mystery and the way all things are intertwined, a person could literally drive their self insane chasing DPC ghosts. I think it is probably very fortunate that most people have no idea whether or not they have some level of DPC latency with their computer.

 

Following on from what you said above about Google Chrome, I decided to install it and see how DPC Latency faired with that browser as opposed to IE9 and the results were quite amazing. Again I ran my test for almost an hour, WMP music looping and this time, Chrome open instead of IE9.

You can see from the shot below that there a no latency spikes - in fact, they are the best results I have had since testing for latency. Also, you can see that hard pagefaults are seriously reduced too for some reason (I dont know why but I like it !).

Another thing VERY worthwhile in pointing out is that the Nvidia Driver is no longer the highest DPC spike - its actually "ACPI.sys - ACPI Driver for NT,Microsoft".

Spoiler

 

Thanks for testing the results with Chrome. It's an awesome browser. Who would have guessed it IE9 would contribute to DPC latency spikes?

One thing I love about Chrome is the sync on the fly feature. I log into my Gmail account on any computer and all of my favorites, toolbar shortcuts, saved passwords, etc. are available from any computer. Log-out and they are gone. It's an amazing browser. I haven't used Firefox in ages, and it used to be my primary browser with IE as backup. I really like IE9 a lot, but I'm hooked on Chrome.

 

Is the latency issue resolved with the latest Nvidia Driver, 296.10?

 

Yes, it is vulcan78. There is one forum member (that I know of) that still has DPC latency, but it may be related to other problems with his system. For most of us it is no longer an issue.

 

I can agree with Mr. Fox - I no longer have any latency spikes with 296.10 (or the previous driver whilst using the P-state adjustment)

 

Moved the discussion over here...

http://forum.notebookreview.com/ali...-overclocking-discussion-103.html#post8398457

 

I thought the DPC Latency was fixed!

 

Bumbo,

What driver are you using buddy? - if its anything other than 296.10 whql, the rest suffer from latency without Brother Fox's "Fox Fix".....that includes the 301.10 modded 680 drivers and the latest official 301.24 beta's. Let's just hope that Nvidia fix what they broke in the new beta driver when they release it as whql, assuming they do that.

 

I'M Using This One,

 

That's why. The new NVIDIA drivers have DPC latency problems... again!

 

I suggest staying away from the latest 300 series drivers after looking through the Nvidia forums lots of users are having issues with them. I myself rolled back to the WHQL 296.10 which have been rock solid.

 

Mr Fox can you sticky this again. Is Bill@Dell able to check the status of this also

 

I agree with the Dan ^^^^^

Maybe Bill or "Team Dell" could nudge Nvidia again - I know its not Dell's problem really but if Nvidia keep dropping the ball, that's no good to any of us with regards to future driver updates if they cant keep them working properly!

 

Agree Brother Steve! Even the whql 296.10 has the DPC latency. This is crazy, coconut, jackityJack and more hehehe. Lol

 

Weird, I will do some more testing on 296.10 but last time I checked, Latency was fine whilst using 296.10 WHQL Drivers.....

EDIT: After Running LatencyMon again for around 50 minutes, I still have the green "good to go" message displayed (this is with Chrome open minimized with four various tabs open) - although latency is a bit higher than I would ideally like - spiking to around 800us caused by the Nvidia Driver 296.10 (200us would be MUCH better for pro-audio work), at least it is passing the test. (see spoiler below). Not quite sure why others are having issues with this still. I wonder what your tests are showing as the highest cause of latency?

Spoiler

 

We have notified Nvidia about the issue. They had it fixed in 296.10, so they just need to figure out how to fix it in this version. They will not release a specific driver for it, but hopefully will get it fixed for their official releases. As for the Dell stance, our older OEM driver works. All we can do is notify Nvidia if we hear about an issue with their retail driver.

 

Chris, you're awesome bro. Thanks for notifying NVIDIA again that their drivers need attention. We appreciate it. +1 rep for passing it on to them.

Has NVIDIA asked Dell to validate the 296.10 driver yet? Overall, it seems to be very solid and may be one that would qualify as the official updated "Dell Recommended" driver.

 

This info is also relevant in this thread...

I wonder the same thing, Brother Steve. There almost has to be something different on the systems that still have the DPC latency. There must be some software package or other driver that is causing it even if it is the NVIDIA driver showing up in LatencyMon as having the issue.

 

Many thanks for keeping on top of this Chris...much appreciated!

I guess the only way to find out would be a clean install and build up from there until the "rogue" is found out....painful, but might work to identify the culprit.

 

acording to latencymon nvd has the highest execution,

 

So i guess the take home from all of this is that we're going to have to be constantly vigilant about latency when new games and then drivers poke their heads?

 

Yes, we sure will have to be. You can use my batch file tweak to mitigate the latency. The realization that a new driver does not necessarily mean a good driver has really come home to roost. Seems AMD and NVIDIA are both doing a poor job of driver development as of late. I hope NVIDIA doesn't get as bad at it as AMD has been the past couple of years.

 

Received new machine today. On first boot it had 296.10 drivers installed and the exact same bad latency. This need to be fixed Nvidia please!!!


Sent from my iPad3 using Tapatalk HD

 

That's really bad news Dan....I wonder if a clean install would maybe help out? - also, was it a brand new system? - only asking because I find it rather odd that upon first boot it had Nvidia Reference drivers installed and not Dell Drivers

 

That is very odd, especially right out of the box. I don't understand why a few are having DPC latency pointing to NVIDIA drivers using the same driver most are not having the issue with. It causes me to wonder if there is not something obscure that is causing it.

 

Hi fellas yes machine is defiantly new. And I thought the same thing when I saw 296.10 drivers installed. Also checked with a torch and thermal pad is not installed on heatsink again.


Sent from my iPad3 using Tapatalk HD

 

That really is odd. Not just about the pad (I havent checked mine but you say its visible through the rear exhausts?) but why you had Nvidia Drivers installed on a brand new rig??????? ( I don't recall seeing a 296.10 Dellized Driver on Drivers & Downloads)

 

That was the first thing I checked after reading Dan's post. No new "Recommended" drivers seen at support.dell.com in the USA.

 

Yeah it's really odd but it started up with the normal Alienware setup (username etc) SLI was turned on and A05 bios. Totally weird ????

Sent from my iPad3 using Tapatalk HD

 

would the DPC latency issue be fixed if you use the A03 bios along with 296 drivers?