If you install software to "view some monitoring", you absolutely cannot say how your system behave when you don't monitor it in background. You're misundersranding fundamental basic principle: GPU Boost 3.0 is NOT handled dynamically on MSI AB or any other software side, it is purely closed NVIDIA driver/hardware technology transparent for applications and you cannot directly alter clock management from software. Besides "safe" mode after TDR the factors that may limit the performance in realtime are reflected on appropriate graphs: power limit, thermal limit, voltage limit and no load limit. This way GPU Boost is giving you some feedback and allowing to see current performance limitation reasons vector. And if it confuses you then peobably the best choice for you would be playing blindly, i.e. without seeing realtime hardware state.

The only reason for a GPU to drop like that is very low GPU utilization / or it kick into a hardware SAFE mode, typically in combo with a driver crash and instability.

This, Happened to me on Fermi, Kepler and now Maxwell when OC'ed too much 🤓

If you install software to "view some monitoring", you absolutely cannot say how your system behave when you don't monitor it in background. You're misundersranding fundamental basic principle: GPU Boost 3.0 is NOT handled dynamically on MSI AB or any other software side, it is purely closed NVIDIA driver/hardware technology transparent for applications and you cannot directly alter clock management from software. Besides "safe" mode after TDR the factors that may limit the performance in realtime are reflected on appropriate graphs: power limit, thermal limit, voltage limit and no load limit. This way GPU Boost is giving you some feedback and allowing to see current performance limitation reasons vector. And if it confuses you then peobably the best choice for you would be playing blindly, i.e. without seeing realtime hardware state.

Monitoring is nothing new to me, it's actually what I do professionally in a large data center. I've always done monitoring on my home PC, did so with my GTX 970 and my GTX 560 Ti before it using Afterburner and my Logitech G15 keyboard. I've been really happy with the software and your work, so it isn't a question in quality of workmanship. I am just trying to figure what is causing this anomaly, whether or not it is directly or indirectly related to Afterburner is what I am trying to determine or if it is just pure coincidence and I need to look elsewhere. I am just starting my path at where the most recent change occurred when the problem started, a process of elimination. And if it was a bug, I just wanted to bring it to someone's attention. I know prior to installing the beta and playing "blindly", I wasn't having such issues because the performance difference and benchmark results are largely different. Also, the sound of the fan when running in "gimped" mode versus normal is quite noticeable too. In "gimped" mode the temps hardly go up enough for the fan to spin up whereas in normal mode you do hear the fan spin up after playing for a bit in games such as GTA V. I was hoping to receive some guidance to find the cause and, ultimately, find a solution from maybe someone else that has experienced similar problems. I'll continue to troubleshoot and will post any updates I come across.

I was hoping to receive some guidance to find the cause and, ultimately, find a solution from maybe someone else that has experienced similar problems.

If you don't see the guidance, it doesn't mean that it is not provided. 😉 Reading the recent posts carefully, you could collect some useful info there and most important find out that your target (i.e. GPU Boost dynamic clock frequency control) lies outside of any software, then try to pay attention to GPU Boost feedback provided in form of performance capping reasons vector. Looking at performance capping related set of graphs in HW monitoring module and seeing which GPU Boost performance limits exactly is holding the clocks you could answer your question.

If you don't see the guidance, it doesn't mean that it is not provided. 😉 Reading the recent posts carefully, you could collect some useful info there and most important find out that your target (i.e. GPU Boost dynamic clock frequency control) lies outside of any software, then try to pay attention to GPU Boost feedback provided in form of performance capping reasons vector. Looking at performance capping related set of graphs in HW monitoring module and seeing which GPU Boost performance limits exactly is holding the clocks you could answer your question.

While I hope it doesn't happen again, I'll take a closer look at the other parameters. But from what I recall, I didn't notice anything else deviating that would cause a cap (e.g., temp was well below threshold, power wasn't fluctuating or capped, fan speed wasn't capped, CPU wasn't heavily loaded, etc.). What is interesting, and maybe you know, is that when this did occur it did not affect the memory clock speed, just the GPU clock speed. Where as in normal desktop and idle scenarios both the GPU and memory clock run at a lower speed (typically GPU at 139 MHz and memory at 405 MHz) and both ramp up when a graphical load occurs, in these instances the memory clock speed would still ramp up to 5000 MHz but the GPU will gimp, only going up to around 865-1066 MHz. Is that normal for when the video card goes into safety mode or when the drivers go unstable? Or is it expected for both GPU and memory clock speed to run lower? Also, I did just stumble on a way to log the monitored data to a file. That will certainly be helpful. Thanks again!

So another weird anomaly popped up. The GPU was clocking in above its core, even boosting to as high as 1850 MHz (which is above stock), of course I am running an OC profile based on Guru 3D's suggestion. Temperature barely cracked above 72 degrees. The odd part is with the OC profile it would usually boost into the 1900's and try to push the 80-82 degrees throttling cap. Performance in game was perfectly fine. The odd part is when reviewing the graphs in Afterburner, the Power % wasn't displaying correctly. Instead of it showing closer to 100% for stock clock and as high as 120% with the OC profile during the loaded runs, the Power % would just constantly show a flat line of 4%, even when in game at a heavy load. Framerate was fine, game ran smooth at 4k maxed out despite this odd spot. Clearly, I don't think the GPU would be hitting 1850 MHz nor 72 degrees if just running at a 4% power load. The rest of the numbers looked fine. Rebooted the PC and power % in the graph started to act normal and in game with an OC profile the GPU clock speed would hover around 1924 MHz with no issue at a temperature of around 79-80 degrees. Again, nothing in Event Logs indicating a driver crash or stability issue.

And another weird anomaly lies outside MSI AB control. Power usage is not calculated inside MSI AB, current usage level comes from NVIDIA driver and being displayed as is.

So another weird anomaly popped up. The GPU was clocking in above its core, even boosting to as high as 1850 MHz (which is above stock), of course I am running an OC profile based on Guru 3D's suggestion. Temperature barely cracked above 72 degrees. The odd part is with the OC profile it would usually boost into the 1900's and try to push the 80-82 degrees throttling cap. Performance in game was perfectly fine. The odd part is when reviewing the graphs in Afterburner, the Power % wasn't displaying correctly. Instead of it showing closer to 100% for stock clock and as high as 120% with the OC profile during the loaded runs, the Power % would just constantly show a flat line of 4%, even when in game at a heavy load. Framerate was fine, game ran smooth at 4k maxed out despite this odd spot. Clearly, I don't think the GPU would be hitting 1850 MHz nor 72 degrees if just running at a 4% power load. The rest of the numbers looked fine. Rebooted the PC and power % in the graph started to act normal and in game with an OC profile the GPU clock speed would hover around 1924 MHz with no issue at a temperature of around 79-80 degrees. Again, nothing in Event Logs indicating a driver crash or stability issue.

Did u remove AB to see if the 'problem' still exists? If No its AB problem. 🙂

Did u remove AB to see if the 'problem' still exists? If No its AB problem. 🙂

Can you stop posting nonsense in AB threads please?

And another weird anomaly lies outside MSI AB control. Power usage is not calculated inside MSI AB, current usage level comes from NVIDIA driver and being displayed as is.

So are you thinking it is either a bad graphics driver install or a bug in the driver that is the main cause (I know Nvidia has already acknowledged at least one bug in the current driver affecting fan functionality)? Or could there be something causing a conflict with the driver? I could attempt a complete uninstall of Nvidia's stuff (both the driver and their Experience software), remove Afterburner and any other applications that might be tapping into the driver (which I can't think of anything other than possibly my Spyder3Elite which creates monitor profiles and accesses the graphics card's LUT). I can then go into safe mode and verify nothing old is still lurking around (eg, the GTX 970 that I had in the PC before the GTX 1080), then start again with a clean install. I have other monitoring software on the PC but, unfortunately, none of them monitor the GPU. Corsair Link allows me to view CPU and motherboard stats (temp and fan speeds only) along with their CPU cooler and ASRock's only allows me to view the motherboard and CPU (voltage and fan speeds, no temps that I recall). Thanks again.

So are you thinking it is either a bad graphics driver install or a bug in the driver that is the main cause (I know Nvidia has already acknowledged at least one bug in the current driver affecting fan functionality)? Or could there be something causing a conflict with the driver?

That's not what I'd be worried about, that's driver bug for sure. There was similar issue with total power reporting stuck at 10% in early branch 361 drivers for Maxwell cards as well and it was eventually fixed by NV. Give Pascal drivers some times to be polished.

Can you stop posting nonsense in AB threads please?

:infinity::infinity::infinity::infinity::infinity:

That's not what I'd be worried about, that's driver bug for sure. There was similar issue with total power reporting stuck at 10% in early branch 361 drivers for Maxwell cards as well and it was eventually fixed by NV. Give Pascal drivers some times to be polished.

Thanks for the speedy reply. I guess I will be patient. This is the first time in a long time that I have been a first adopter of a new video card. I've usually waited a bit before buying a new video card. If it wasn't for me upgrading to a 4K monitor, I would have waited. I think the last time I jumped on the early band wagon was back in the 2001-2002 with the Geforce 3/4 and All-In-Wonder 9700 Pro. At the very least the problems are not catastrophic and are fairly easy to fix (thankful for my Samsung 950 Pro M2 and quick reboots). It's just annoying at this point.

Its not nonsense, Dont try to convince people that your software dont have BUGS.

Don't you assume that probably I can see a "bit" deeper than you which task are performed inside this software and which tasks are out of its control and performed inside display driver and hardware? I'm starting getting tired of your strange posts in 4.3.0 beta threads, starting from requests to improve Tonga voltage control, debates about Tonga EOL (when in fact even Fiji is not a development priority now) and ending by statements declaring that releasing new beta just for Pascal has no sense. That is what I call nonsense and I'd really like to avoid wasting time on commenting it. Stop that please.

Don't you assume that probably I can see a "bit" deeper than you which task are performed inside this software and which tasks are out of its control and performed inside display driver and hardware? I'm starting getting tired of your strange posts in 4.3.0 beta threads, starting from requests to improve Tonga voltage control, debates about Tonga EOL (when in fact even Fiji is not a development priority now) and ending by statements declaring that releasing new beta just for Pascal has no sense. That is what I call nonsense and I'd really like to avoid wasting time on commenting it. Stop that please.

Unreal. Im out.:puke2:

I'm curious, while I understand that Afterburner needs to be running in the background in order for the custom fan and OC profiles to work, does it need to keep in constant contact with the video card in order for it to retain the profiles? As an update, I am still seeing the issue I described before. However, this time I decided to do a clean uninstall of the drivers and software. I uninstalled Afterburner, Riva Tuner, Geforce Experience, and used DDUD to completely remove the video card drivers. I then installed the latest Nvidia driver 368.39. Everything seemed to be working fine with just the drivers (basing on benchmarks and actual gameplay, furmark showed me clock speeds). I then installed Afterburner. At first everything seemed to be working fine with no issues. I ran several tests and played through my games quite a bit with no problem. Then the problem started to come back. But this time I had profiles saved in Afterburner. So instead of rebooting the PC, I would just change the profile. Once I selected a different profile the issue would resolve itself and run fine until the next time it acted up. I've even done this "profile reset" mid game where after loading up the game, I noticed the clock speed didn't ramp up and the game's frame rate was very low, choppy. I minimized the game window, opened Afterburner and refreshed the profile, and went right back into the game right where I left off. The game ran perfectly fine at full clock speeds (including boost) without issue for the next hour or so I was playing. Again, nothing in the event logs indicating a failed driver. The chart data looks no different than before, memory speeds seem to be unaffected when this happens, the GPU clock speed that it caps at wouldn't always be the same (sometimes in the 800s, sometimes in the low 1,000s, etc.). The only commonality that I see is that I notice whenever the problem does occur it is when I bring the monitor out of sleep. I have the machine's power profile set to high performance, the machine does not get powered off, hibernate, nor put to sleep. Only the monitor is set to go to sleep after 20-30 minutes. I don't recall it happening every time the monitor goes to sleep, but when it does occur it is after the monitor comes out of sleep (I've never seen it happen while actively using the machine or in the middle of gaming). The 4k monitor is connected via DisplayPort and is G-sync enabled. DisplayPort Deep Sleep has been disabled.

Unwinder, can you please add the following to the rtss applications profile list and set application detection level to none for all 3? PowerDVDMovie.exe PowerDVD16Agent.exe PowerDVD16ML.exe

Did u remove AB to see if the 'problem' still exists? If No its AB problem. 🙂

That's a common misconception. Bear with me please. You could have a perfectly healthy system, and AB could be 100% bug free and working as intended. Yet your system + AB = kaboom! And then you say, ah but all I've added is AB. So it must be AB's fault, right? RIGHT? Wrong. Your perfectly healthy system was deemed healthy by you doing CD, EF, GH etc kind of things. Yet if it does a perfectly legal operation which AB asks it to do, it brakes. It does not mean its AB bug. In fact in this little hypothetical, yet perfectly plausible example of mine - it's clearly your PC's fault.

Another update: This past Sunday I decided to disable the option to have my monitor go to sleep after a set time period. Ever since I have disabled that I haven't run into gimped clock issue. Now it has only been just short of a week, so it isn't definitive, but this is the longest I have gone without issues (before the issue would occurred at least once or twice a day). Of course, now I have to remember to turn off my monitor manually every time I step away from the computer, but at least the clock speeds on the GPU are not acting up. As mentioned before, I don't have any other power save features enabled on the PC. Windows is set to High Performance, C-State is disabled in the BIOS, and sleep and hibernate options are disabled. I only had the monitor go to sleep after 20-30 minutes. Now the question is why does the monitor power save option randomly gimp the GPU clock speed? Secondly, is it just the video driver itself that is at fault or is it a combination of Afterburner's interaction that is causing the problem (this is where earlier I was questioning what Afterburner needs and does to communicate with the video card)? Something else? I've never had this happen before. On another note, I know the app is still in beta, but I did notice something weird occur once or twice with it when tinkering with overclocks. I decided to use the curve chart to set my overclocks, which worked great (I did the shift click drag method to adjust the whole curve at the same time). But once or twice the app acted like it "forgot" the curve setting and reverted my settings to a lower, previously set overclock (which was set using just the slider method). It was either after a reboot or closing and reopening the app when this occurred. My overclock was saved as a profile, yet it changed/reverted the profile. Something random.

I'm curious, while I understand that Afterburner needs to be running in the background in order for the custom fan and OC profiles to work, does it need to keep in constant contact with the video card in order for it to retain the profiles?

You're misunderstanding fundamental thing. AB doesn't need to be running in background for custom OC profiles to work. Overclocking is not a dynamc process for any OC software and I repeated a few times in this thread that GPU Boost clock controller is doing all the dynamic clock/voltage control job independently of any applications. The only thing thah is done by AB or any other similar overclocking applications is passing desired clock/voltage offsets to NVIDIA driver, it is being done just ONCE when you specify new clock settings and click "Apply" or load previously defined OC settings via profile. All the subsequent dynamic clock freqency changes are NOT HANDLED BY SOFTWARE.