Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by skizzo, Jan 8, 2018.
The intervals between peaks are different which means that it clearly doesn't.
The intervals are the same, look again. I measured them all out. The red lines are 15 pixels wide. I don't know how you can't see this.
One last try. Left half is no power monitoring. Right half it is on. This is 100ms monitoring with 0 interleave. Honestly if you can't see the regularity of these spikes you're blind.
You obviously don't know what you're talking about. The regularity means little, its the evenness of the polling period which is important. Your spikes aren't separated by even intervals which means that it's unlikely due to power monitoring.
Also let me repeat myself: I don't have this issue.
Repeating yourself doesn't make the graphs any less true. We're done here.
You mean you're done here since so far your the only one reporting such issue.
It did feel like I had some stutters after coming from the most recent 388.xx driver up to this driver. After seeing your recent posts I'm going to look into whether or not the power monitoring helps in my case. I have a few questions for you. Did you upgrade from your last driver, normal uninstall or DDU? What exact versions of MSIAB/RTSS are you on right now? Did you change any settings in the NVCP or in NPI after moving to this driver?
EDIT - So I just spent a few hours playing Wasteland 2, Shadow of War and Sniper Elite 3. Lo and behold, all of them had a predictable and evenly spaced stutter going on until I turned off the power monitoring in MSIAB. I used repeatable sequences in all 3 games to test first with it on, exit the game and look at the frametime graph, turn it off and then start up the games and run the same sections. After turning just the power monitoring off it was either perfectly smooth, or in the case of Wasteland 2, nearly perfect.
I'm going to keep an eye on this from now on when changing driver and MSIAB versions.
I have windows patched for the fix but the latest bios for my motherboard including the microcode is very unstable so I am skipping it until a new bios gets released. I noticed right away after I plugged in my OC settings, the computer hung and wouldn't boot. It would only boot after hitting the reset button. Every other bios works perfectly fine. That being said, unless I missed something, these vulnerabilities haven't even been used yet by hackers. So I'd say there isn't a rush to patch the bios.
I guess that explains why i'm one of the few that didn't have stuttering issues with this driver, i still had it disabled from last time
Because he is the only one doesn't necessarily mean that there is no issue or that its PC has specific issues unrelated to driver...
The only parameter he changes is power monitoring, and we can clearly see the regularity of the spikes over time : the period looks even to me, with 4 columns each time in between. Although I agree that the ramping up is totally different between each spikes.
So there is a form of period but with some small "glitches"...
Nevertheless, I reiterate that it's not because he is the only one reporting that the issue is not there (i.e. issue with the driver 390.65 whereas a "similar" bug was supposedly solved in previous release).
It was a normal upgrade at first, which in my case is custom and I uncheck the geforce experience box. When I realised there was a problem, I tried a DDU uninstall and then reinstalled again, this time I also unchecked the 3d drivers since I don't use them. Was still the same.
AB is v220.127.116.1163
RTSS is v18.104.22.16896 (Both the latest afaik)
In NVCPL I disable vsync and set power management mode to adaptive. For game profiles (only BF1 thus far) I set power management mode to maximum power. This is the norm for me and I did this in both cases. As a troubleshooting step, I tried disabling threaded optimisation (as I thought the stuttering may be a result of the spectre fixes) and this seemed to have an effect but later tests showed it to be ineffective in most cases (it seems only BF1 changed and not much at all) and I have since set it back to auto.
In NPI, I set Force CUDA P2 state to OFF, as I use NVENC and don't need a downclock when recording my games. This is the norm for me and I tried it at the default but again no change.
I wouldn't worry too much about it in general.... What will have happened here, is that some months ago, Nvidia will have branched off the v387 code, and started work on the v390 branch. What we are seeing here is identical behaviour to the 388.13 driver which introduced the power monitoring bug*, so it stands to reason (we can only guess) that the code they used to start on 390, was 388.13.
They would have had two concurrent branches of code, one they were releasing to us in the 38* drivers, and another they worked on in-house to prepare for the 39* drivers. When 390 was ready to release, it would have had some code which was based on the earlier driver, some new stuff made especially for 390, and then some which were written intended for inclusion in 388.* but then also merged into the 390 branch. They'll have just made an 'oops' and forgot to merge this fix (hopefully no others!). It's not something I would expect to see happen again, since they will merge the fix into 390 and the next branch off of that, would be based on the fixed code.... Then again, if it can happen once.......
* The interesting thing about this bug is that it does not cause spikes which match the polling frequency of the monitoring tool. This was also the case in 388.13. What it seems (again, we can only guess) is occurring, is that the very act of monitoring power, causes a change in power draw (or perhaps just the sense of power draw, as in the numbers are changing but not the actual draw). It makes sense, given the way GPU boost works, that the change in power draw has an effect on performance. The last graph I posted (the big one, polling at 100ms intervals) shows this very clearly. Although the spaces between the spikes in frametimes are not exactly evenly spaced (note they are a little closer together at the beginning), they are exactly correlating to the wave of power draw. This smells like the wrong bytes have been written to the power management circuits on the card.
I dont know if it is this driver but some time after a reboot my hz is set to 100-120 instead of 144hz, and some time i boot with the lowest resolution and missing all other resolutions. I have use DDU but that dont fix this problem what i have. This is happen to me after installing driver 390.65 on Windows 10 1709, GTX 1080 ti msi gaming x monitor Samsung c32hg70 DP 1.4 and tried 2 difference DP1.4 cables.
What is this I've been suffering lately since 388.71 and watching twitch with Firefox 57... including 390.65.
Event id 4101 "Display driver nvlddmkm stopped responding and has successfully recovered."
Hmm, seems these issues started for me when I upgraded to Quantum a week or two ago.
Thanks so much for the post. This stopped my "hitching" / micro-stutter problem with these drivers. It was driving me crazy and I had no idea what to do.
You're welcome. Since the stuttering is widespread and this has fixed it for all but one person so far, I've reported it to nvidia. I think we can expect a fix in the next release or so.
And again a low resolution after boot. Monitor reset/clearing helps so i think now its my monitor?
I can confirm the Power Monitoring bug causing stutter.Noticed it the night before but needed to be sure.Even though my performance was still up, slight stuttering would occur every now and then in Watch Dogs 2.It would go away for a while but then come right back.
Disabled power monitoring in AB and I couldn't believe how smooth it was.Nice catch.
I was gona install these drivers solely for the meltdown/spec issue when I stuck my 660 gtx back in while I send my 1060gtx SSC in to evga for 1070ti black threw set-up.
But I just pulled the 1060gtx out and threw the 660gtx back in with the drivers already there. so far everything seem to be working like it should be, so less something happens I will install these when I get 1070ti from the set up. which I should get the 1070ti black next friday, or following monday providing there is no delays
I haven't been playing many games since before Christmas so, although these drivers are installed, I haven't really tested them in anything other than about 20 minutes of Assassin's Creed: Origins. However, I will check for microstuttering over the weekend as I noticed it straight away with an earlier v38x.xx driver while playing Hollow Knight. Although it's a 2D platformer, the stutter is immediately obvious when the game scrolls left or right as there are hitches one second apart (as the polling is set to 1000ms in Afterburner).
Will report back here on my findings. I would very surprised if this bug is back though after NVIDIA fixed in a later v38x.xx driver...
When you connect the TV via HDMI, the FPS has fallen simultaneously on the monitor and TV.
Not in games, but in general on the screen. Movies go with brakes, as well as online viewing of Youtube.
On the previous drivers this was not.
After some further testing, looks like it isn't the same pwr monitor bug that got fixed.
If I leave Pwr Monitoring on in AB and set Pwr Management for the app (Watch Dogs 2) to Default (Optimal) in Nvcpl, there's no stutter at all.
If I set Pwr Management to Adaptive or Prefer Max Perf., the stuttering comes back, unless I disable the AB plugin.
Whatever glitch this is, it's affecting everyone to varying degrees.
Just a fyi for the curious, no matter what power management option I chose for the game, the gpu was at full overclock.