MSi Afterburner Potential 1% Lows & Stutter Issues - FIXED

[oliv_r]

TLDR; MSI Afterburner's 'Power' & 'Power Percent' causes very bad 1% Lows to the point that it completely stutters your game. Therefore disable them, likewise:

This was tested by other people in this reddit thread, Dannyz (YouTube), my wife and I's respective gaming PCs (5950X & 3950X). My 5950X & 4070 Ti Super was struggling against huge mobs in Path of Exile 2 for the past two weeks since launch to the point where I had to lower all settings. But even then, same bad Lows and stutters persist even if I go 720p.

This all changed when I ran into Dannyz video, linked above and confirmation from other testers in the reddit thread linked above as well. I implemented their suggestions on both rigs at home and voila: my frametimes had been immaculate, 1% Lows are upwards of 110+ fps, no more stutters and GSync is functioning fine on the highest settings for PoE 2. I have yet to test other games but I am confident it will do the same thing: give me a smoother and better gaming experience.

google search tags: fix stutter amd cpu 5950x 9800x3d "x3d" poe 2 reddit msi afterburner techpowerup tech power up issue latency frametime frame time fps 2023 2024 2025

 

[harm9963]

TLDR; MSI Afterburner's 'Power' & 'Power Percent' causes very bad 1% Lows to the point that it completely stutters your game. Therefore disable them, likewise:
View attachment 377119

This was tested by other people in this reddit thread, Dannyz (YouTube), my wife and I's respective gaming PCs (5950X & 3950X). My 5950X & 4070 Ti Super was struggling against huge mobs in Path of Exile 2 for the past two weeks since launch to the point where I had to lower all settings. But even then, same bad Lows and stutters persist even if I go 720p.

This all changed when I ran into Dannyz video, linked above and confirmation from other testers in the reddit thread linked above as well. I implemented their suggestions on both rigs at home and voila: my frametimes had been immaculate, 1% Lows are upwards of 110+ fps, no more stutters and GSync is functioning fine on the highest settings for PoE 2. I have yet to test other games but I am confident it will do the same thing: give me a smoother and better gaming experience.

google search tags: fix stutter amd cpu 5950x 9800x3d "x3d" poe 2 reddit msi afterburner techpowerup tech power up issue latency frametime frame time fps 2023 2024 2025

Never had that issue, power percent and power, only use power for display and monitoring -Tray icon / power percent only in monitoring , but I only play at 4K .

 

[oliv_r]

Never had that issue, power percent and power, only use power for display and monitoring -Tray icon / power percent only in monitoring , but I only play at 4K .

It's case by case - for most, people with X3D chips were seeing the issue. For some reason same thing applied to my heavily PBO'd 5950X (-15 fastest four, -25 rest). I also tested it with Afterburner's monitoring window open in my other screen. When it was enabled, the moment Power started spiking up, my game, in this case PoE 2, started stuttering. I also tested turning off Auto Start on Afterburner and performance was fine (this was before unchecking Power & Power Percent) - I utilized GPU-Z to monitor sensors; no bad dips and stutters.

But like I said, extremely case by case but behavior mostly affected X3D chip owners.

 

[mkdr]

It is the same bug as I reported a year ago on here with HwInfo, happens with both HwInfo and MSI AB mostly also other tools:

Read through all posts on here:

HwInfo causing FPS drop anomalies on Nvidia GPUs with VSync

There is a weird bug since months in combination of Nvidia drivers on Windows 11 and HwInfo running, causing FPS not be stable at VSync cap. If you have a monitor which doesnt support Gsync, so it just uses VSync, and have HwInfo running, there is a weird glitch happening, that the FPS is not...

www.hwinfo.com

HwInfo causing FPS drop anomalies on Nvidia GPUs with VSync

Well I did some gaming test (avatar FOP, which is know to be quite well optimized, at least for frametime) and the result is that HWinfo64 GPU monitoring is somehow creating frametime spikes when Vsync is on. See below picture, on the top, with HWinfo64 GPU monitoring (1000ms pooling), it...

www.hwinfo.com

"It seems to me that the scope of the issue is wider than just NVML. In my case, HWiNFO GPU monitoring is causing frametime spikes even if I disable monitoring of all GPU sensors and NVML (but keep GPU monitoring enabled). By comparison, MSI Afterburner causes frametime spikes only if GPU Power monitoring is enabled. And the root cause of this behavior is NVAPI power call by itself (I verified it myself by calling NvAPI_GPU_ClientPowerTopologyGetStatus). So, I'm making a conclusion that NVAPI calls for GPU Power metrics are flawed. But other metrics should work without noticeable issues. Which is not the case with HWiNFO for some reason even if NVML is disabled."

The micro stutters happen with all kinds of tools which read power stats from Nvidia GPU.

I had also reported this btw to the autor (unwinder) of MSI AB and RTSS, and he answered in the same ignorant way as he always does, claiming it had nothing to do with it.

 

[eidairaman1]

TLDR; MSI Afterburner's 'Power' & 'Power Percent' causes very bad 1% Lows to the point that it completely stutters your game. Therefore disable them, likewise:
View attachment 377119

This was tested by other people in this reddit thread, Dannyz (YouTube), my wife and I's respective gaming PCs (5950X & 3950X). My 5950X & 4070 Ti Super was struggling against huge mobs in Path of Exile 2 for the past two weeks since launch to the point where I had to lower all settings. But even then, same bad Lows and stutters persist even if I go 720p.

This all changed when I ran into Dannyz video, linked above and confirmation from other testers in the reddit thread linked above as well. I implemented their suggestions on both rigs at home and voila: my frametimes had been immaculate, 1% Lows are upwards of 110+ fps, no more stutters and GSync is functioning fine on the highest settings for PoE 2. I have yet to test other games but I am confident it will do the same thing: give me a smoother and better gaming experience.

google search tags: fix stutter amd cpu 5950x 9800x3d "x3d" poe 2 reddit msi afterburner techpowerup tech power up issue latency frametime frame time fps 2023 2024 2025

Ever report this to msi?

 

[AlexUnwinder]

> I had also reported this btw to the autor (unwinder) of MSI AB and RTSS, and he answered in the same ignorant way as he always does, claiming it had nothing to do with it.

Not everything you report is valuable. And not every answer you get is ignorant, it may be simply just a bit beyond of your technical info understanding level. If you reread your own quote a few times, you'll probably understand why it not up to me, Martin or Michael to fix anything in our tools.

The bootleneck is well known for decade, documented in each tool's support and it is located inside NVIDIA driver's NvAPI_GPU_ClientPowerTopologyGetStatus and CPU stalls there. That's why HwInfo includes monitoring profiling tool, allowing you to identify such sensor. That's why MSI AB contains performance profiling tool. And that's what skilled users use to troubleshoot such issues in _seconds_. But some reviewers like author of this video have no ideas that such toolsets exist and prefer to host hype clickbait videos with wrong conclusions.

 

[:D:D]

And the root cause of this behavior is NVAPI power call by itself (I verified it myself by calling NvAPI_GPU_ClientPowerTopologyGetStatus). So, I'm making a conclusion that NVAPI calls for GPU Power metrics are flawed.

Have you tried nvmlDeviceGetPowerUsage instead?

 

[AlexUnwinder]

nvmlDeviceGetPowerUsage usage won't solve anything because:

- nvmlDeviceGetPowerUsage reports absolute power in watts, sampled from power sensor. NvAPI_GPU_ClientPowerTopologyGetStatus reports GPU power in % of TDP and total normalized GPU power in % of TDP requested from power limit controller. Those are different and more resource heavy sensors from polling POV. For absolute power reporting NVAPI provides alternate and way more detailed (comparing to NVML) per-rail GPU power reporting interface, which is pretty fast and not affected.
- NVML is targeted on Quadro/Tesla families only, it is not guaranteed to work on GeForce family and not officially supported there by NV, so it is a no go for any forms of partner's software

 

[:D:D]

@AlexUnwinder Thanks, good to know. As a hobby programmer who writes their own software I don't have to worry so much about 'officially supported' and find nvml good enough for my own needs, perhaps @mkdr is in the same position?

Some comparison

Calls 1 per second

Linux Fedora 41
p8
nvapi power 16W, 35773.9 µs
nvapi power 15W, 35877.8 µs
nvapi power 16W, 37903.5 µs
nvapi power 16W, 36006.9 µs
nvapi power 15W, 36131.4 µs
nvml  power 16W,  4184.8 µs
nvml  power 16W,     7.6 µs
nvml  power 15W,     7.3 µs
nvml  power 16W,     7.2 µs
nvml  power 16W,     7.1 µs

p0
nvapi power 36W, 27242.7 µs
nvapi power 36W, 27462.3 µs
nvapi power 36W, 24521.5 µs
nvapi power 36W, 27354.4 µs
nvapi power 36W, 26275.7 µs
nvml  power 36W,  1512.1 µs
nvml  power 36W,     7.6 µs
nvml  power 36W,     7.4 µs
nvml  power 36W,     6.6 µs
nvml  power 36W,     6.6 µs


Windows 10
p8
Nvapi power 12W, 22166.7 µs
Nvapi power 12W, 11759.6 µs
Nvapi power 12W, 13315.3 µs
Nvapi power 12W, 12423.1 µs
Nvapi power 13W, 11771.2 µs
Nvml  power 12W,   415.7 µs
Nvml  power 12W,     4.7 µs
Nvml  power 12W,     4.0 µs
Nvml  power 12W,     4.3 µs
Nvml  power 12W,     2.4 µs

p0
Nvapi power 36W, 12130.2 µs
Nvapi power 36W, 12324.0 µs
Nvapi power 36W, 12460.1 µs
Nvapi power 36W, 15560.2 µs
Nvapi power 36W, 13480.8 µs
Nvml  power 36W,   421.8 µs
Nvml  power 36W,     4.6 µs
Nvml  power 36W,     4.5 µs
Nvml  power 36W,     2.5 µs
Nvml  power 36W,     2.3 µs

Over 30ms under Linux, yuk! and personally I've never liked those TGP percentages, would rather have Watts.

Of course Nvapi can be difficult for me not having much in the way of documentation but means having to learn through some guess work and testing which can be quite rewarding IMO. For instance early days of Pascal saw P2 introduced with lower memory clock than P0. People running software in P2 maxing their memory clock for it would have a problem if state changed to P0 as memory clock would be too high and crash. I discovered back then it was possible to offset P2 so memory clock was the same in both P0 and P2. Makes P2 pretty redundant in that case but then again when the first Pascal driver came out there wasn't a P2 state to begin with, that came later.

The cool thing is I can try 'unofficial' stuff without worrying about users getting angry if it breaks because there aren't any

 

[mkdr]

@:D:D Thanks for testing this. Read the forum post in the HwInfo Forum from above from page 1-4. Turning off Nvml actually was the fix in HwInfo for the framedrops in combination with VSync (doing ufo test for example as a quick test). Not sure how that is being explained when Nvml has way better reading behavior, youre right 30ms with Nvapi is insane and that is unaccetable and shouldnt be used at all. There should also be a warning inside MSI AB, if you toggle on the power reading, to warn about it could cause issues. If @AlexUnwinder knew about this, he should have put a warning into MSI AB for people to know about it. And with that I mean a warning inside the GUI, not inside some readme.txt no one is aware of. This is a wider issue than most assume I guess, because a lot of reviewers use HwInfo and especially RTSS at some point to benchmark, and power reading is always being used. Nvidia just commented on this by this quote:

"We've observed an issue where stutter will be introduced into gameplay if diagnostic tools are running such as Afterburner, HWiNFO, etc.. Please use alternative tools during your testing such as FrameView."

At this point I mostly would just disable monitor reading in MSI AB at all, and also not using HwInfo. It is nice to have OSD with power data, but at its cost, it is not usable.

 

[:D:D]

Don't know what you mean about 'turning off nvml'?

 

[mkdr]

@:D:D There is a toggle option in HwInfo to use NVML, it is on by default. If it is activated with HwInfo running, it causes framedrops. Read the above forum post 1-4.

HwInfo causing FPS drop anomalies on Nvidia GPUs with VSync

You can see the entire issue in this video happening, with all steps. how it is still working, until you open sensors, then you need to wait a little bit about 10-20 seconds, issue starts to randomly happen. closing sensors doesnt stop it to happen, until fully closing hwinfo...

www.hwinfo.com

 

[:D:D]

Ahh, okay. I'm not so familiar with HWINFO these days but occasionally use it for demonstrating something as it's a bespoke app that many people know.

I thought you might have meant both nvapi and nvml running together causing some problems so just tried running nvapi only with my own SW and no difference.

 

[mkdr]

Maybe there is some bug still in HwInfo too which causes this behavior in combination with NVML. I am not sure how HwInfo reads the power data from GPU actually in combination with the toggle for NVML on/off, if there is a flaw maybe that it uses both at the same time, which I doubt.

 

[AlexUnwinder]

@AlexUnwinder Thanks, good to know. As a hobby programmer who writes their own software I don't have to worry so much about 'officially supported' and find nvml good enough for my own needs, perhaps @mkdr is in the same position?

He is not in the same position because he is not developer. That's just an attempt to speculate blindly about things read somewhere.

Of course Nvapi can be difficult for me not having much in the way of documentation but means having to learn through some guess work and testing which can be quite rewarding IMO. For instance early days of Pascal saw P2 introduced with lower memory clock than P0. People running software in P2 maxing their memory clock for it would have a problem if state changed to P0 as memory clock would be too high and crash. I discovered back then it was possible to offset P2 so memory clock was the same in both P0 and P2. Makes P2 pretty redundant in that case but then again when the first Pascal driver came out there wasn't a P2 state to begin with, that came later.

Your NVAPI timings (Win version) are rather typical for NvAPI_GPU_ClientPowerTopologyGetStatus (TDP % status) calls (10-15 milliseconds average), but they are rather high for NVAPI absolute power reading. Linux results are out of context, because NVAPI is not native API there.
Which NVAPI calls exactly did you try to profile? NVAPI based implementations for both relative (TDP % status) and absolute GPU power reading (Watts) are demonstrated inside RTSS SDK (.\SDK\Plugins\Client\OverlayEditor\NVAPIWrapper.cpp) in both GetCurrentRelPower() and GetCurrentAbsPower(). For absolute power reading it contains single NvAPI_GPU_PowerMonitorGetStatus call, which is normally below 1ms.

It is common pattern for any monitoring tool to provide you all available sensors enabled by default. AIDA works this way. HwInfo works this way. GPU-Z works this way. ASUS GPU Tweak works this way. EVGA Precision works this way. MSI Afterburner works this way. Every other vendor's own hardware monitoring software works this way. All of them give you full set of supported sensors enabled by default and allow you to disable everything you don't need and this way minimize and exclude any possible monitoring related performance hit. Are all of those products (which are developed by completely different ppl) "monkey business" tools? And their "pro coders" just blame mere mortals instead of doing things properly? Is it a case of MSI AB dev doing something stupid, or it is a case of you misunderstanding something pretty trivial?
Reality is that any form of monitoring always eat some performance. It was always so, and it will be always so. That's an absolute axiom. Each additional enabled sensor increases performance hit. Some eat more, some eat less, but none of them is absolutely free. That's also an axiom.
Some monitoring tools provide you performance profiling features, allowing you to identify and disable slow sensors. Ironically enough, MSI AB contains the most detailed monitoring performance profiler but it still gets hate and blame from "knowledgeable" users due to such clickbait videos.

And please, no need to tell me that AMD's monitoring API is much better and do not suffer from such issues. This way you'll immediately prove that you _never_ programmed anything for AMD GPUs. If you don't believe me, than probably you'll believe 1usmus?

Why did you remove the defaults values? Why did you remove VRAM usage? Mapping for timings? · Issue #8 · GPUOpen-LibrariesAndSDKs/ADLX

 

[mkdr]

Time to put Unwinder also on ignore in this forum. What a lovely person he is.

 

[Solaris17]

These personal attacks need to stop now. SMH all around.

 

[Waldorf]

have know about any "power" measuring to impact perf for a while now, and know its not only AB doing this, still dont understand why anyone would need to keep monitoring enabled,
after doing settings/tweaks etc., its not like the other features stop working, and the fact all "monitoring" will have at least a minimal impact, so i disable anyway.
and unless your messing with flashing, what good is it going to do to keep running (power) monitoring, as once i measured (to know) the max the gpu can draw,, thats not gonna change.

 

[:D:D]

Your NVAPI timings (Win version) are rather typical for NvAPI_GPU_ClientPowerTopologyGetStatus (TDP % status) calls (10-15 milliseconds average), but they are rather high for NVAPI absolute power reading. Linux results are out of context, because NVAPI is not native API there.
Which NVAPI calls exactly did you try to profile? NVAPI based implementations for both relative (TDP % status) and absolute GPU power reading (Watts) are demonstrated inside RTSS SDK (.\SDK\Plugins\Client\OverlayEditor\NVAPIWrapper.cpp) in both GetCurrentRelPower() and GetCurrentAbsPower(). For absolute power reading it contains single NvAPI_GPU_PowerMonitorGetStatus call, which is normally below 1ms.

That Linux nvapi library is part of nvidia's Linux driver package, in this case 'NVIDIA-Linux-x86_64-565.77.run'. Calls are made by way of 'nvapi_QueryInterface', both use same integers for functions although less functions on Linux, about 500+. Had a look at NvAPI_GPU_PowerMonitorGetStatus as suggested, thanks. Results below.

W10
p8
NvAPI_GPU_ClientPowerTopologyGetStatus 13W, 12325.3 us
NvAPI_GPU_ClientPowerTopologyGetStatus 14W, 12212.7 us
NvAPI_GPU_ClientPowerTopologyGetStatus 13W, 12153.4 us
NvAPI_GPU_ClientPowerTopologyGetStatus 13W, 11766.2 us
NvAPI_GPU_ClientPowerTopologyGetStatus 13W, 11878.0 us

NvAPI_GPU_PowerMonitorGetStatus        13W,  2004.6 us
NvAPI_GPU_PowerMonitorGetStatus        14W,   906.4 us
NvAPI_GPU_PowerMonitorGetStatus        15W,  1193.7 us
NvAPI_GPU_PowerMonitorGetStatus        14W,   923.2 us
NvAPI_GPU_PowerMonitorGetStatus        13W,  1245.8 us

nvmlDeviceGetPowerUsage                13W,   560.7 us
nvmlDeviceGetPowerUsage                14W,     4.6 us
nvmlDeviceGetPowerUsage                13W,     2.4 us
nvmlDeviceGetPowerUsage                13W,     2.5 us
nvmlDeviceGetPowerUsage                13W,     4.3 us

p0
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 14479.6 us
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 15206.6 us
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 14909.6 us
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 14898.4 us
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 15399.1 us

NvAPI_GPU_PowerMonitorGetStatus        37W,  2128.0 us
NvAPI_GPU_PowerMonitorGetStatus        37W,   643.5 us
NvAPI_GPU_PowerMonitorGetStatus        37W,   657.9 us
NvAPI_GPU_PowerMonitorGetStatus        37W,   711.9 us
NvAPI_GPU_PowerMonitorGetStatus        37W,  1886.6 us

nvmlDeviceGetPowerUsage                36W,   433.6 us
nvmlDeviceGetPowerUsage                36W,     2.6 us
nvmlDeviceGetPowerUsage                36W,     5.8 us
nvmlDeviceGetPowerUsage                37W,     4.5 us
nvmlDeviceGetPowerUsage                36W,     2.4 us

Linux

p8
NvAPI_GPU_ClientPowerTopologyGetStatus 14W, 37347.8 us
NvAPI_GPU_ClientPowerTopologyGetStatus 15W, 35770.5 us
NvAPI_GPU_ClientPowerTopologyGetStatus 14W, 34827.4 us
NvAPI_GPU_ClientPowerTopologyGetStatus 14W, 35721.6 us
NvAPI_GPU_ClientPowerTopologyGetStatus 14W, 36991.6 us

NvAPI_GPU_PowerMonitorGetStatus        14W,  4448.4 us
NvAPI_GPU_PowerMonitorGetStatus        14W,  4925.6 us
NvAPI_GPU_PowerMonitorGetStatus        14W,  4322.2 us
NvAPI_GPU_PowerMonitorGetStatus        14W,  4103.5 us
NvAPI_GPU_PowerMonitorGetStatus        14W,  9236.4 us

nvmlDeviceGetPowerUsage                14W,  5002.3 us
nvmlDeviceGetPowerUsage                14W,     7.5 us
nvmlDeviceGetPowerUsage                14W,     6.2 us
nvmlDeviceGetPowerUsage                14W,     6.9 us
nvmlDeviceGetPowerUsage                14W,     6.2 us

p0
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 29215.3 us
NvAPI_GPU_ClientPowerTopologyGetStatus 37W, 25165.9 us
NvAPI_GPU_ClientPowerTopologyGetStatus 36W, 24792.9 us
NvAPI_GPU_ClientPowerTopologyGetStatus 37W, 24454.7 us
NvAPI_GPU_ClientPowerTopologyGetStatus 37W, 27771.0 us

NvAPI_GPU_PowerMonitorGetStatus        36W,  2054.8 us
NvAPI_GPU_PowerMonitorGetStatus        36W,  2223.9 us
NvAPI_GPU_PowerMonitorGetStatus        37W,  2235.1 us
NvAPI_GPU_PowerMonitorGetStatus        36W,  2250.4 us
NvAPI_GPU_PowerMonitorGetStatus        37W,  2303.9 us

nvmlDeviceGetPowerUsage                37W,  1518.3 us
nvmlDeviceGetPowerUsage                37W,     6.3 us
nvmlDeviceGetPowerUsage                37W,     7.1 us
nvmlDeviceGetPowerUsage                37W,     7.1 us
nvmlDeviceGetPowerUsage                37W,     7.0 us

Note that I'm not a developer and have no plans to produce any apps. As I have limited HW the programming is a lot easier and provides a great way to play around with it. Also mainboard / CPU is ten years old now. While IMO AB has a really nice looking GUI, I don't usually have a one for setting values, just recompile and run once for changes and what I do have is pretty ugly. For me it's more like puzzle solving, some people like crossword puzzles, I like hardware puzzles and I guess it helps to exercise the brain, shame about my memory though.

Thanks for the "NvAPI_GPU_PowerMonitorGetStatus" tip, if I need connector powers also it will come in handy.

 

[DeathtoGnomes]

IDK how long I have had Gpu monitoring off so after reading this thread, I decided to test things with this setting on and can confirm my games started stuttering a tiny bit, its annoying.

(click system specs over << there)

 

[Koozwad]

It is common pattern for any monitoring tool to provide you all available sensors enabled by default. AIDA works this way. HwInfo works this way. GPU-Z works this way. ASUS GPU Tweak works this way. EVGA Precision works this way. MSI Afterburner works this way. Every other vendor's own hardware monitoring software works this way. All of them give you full set of supported sensors enabled by default and allow you to disable everything you don't need and this way minimize and exclude any possible monitoring related performance hit. Are all of those products (which are developed by completely different ppl) "monkey business" tools? And their "pro coders" just blame mere mortals instead of doing things properly? Is it a case of MSI AB dev doing something stupid, or it is a case of you misunderstanding something pretty trivial?
Reality is that any form of monitoring always eat some performance. It was always so, and it will be always so. That's an absolute axiom. Each additional enabled sensor increases performance hit. Some eat more, some eat less, but none of them is absolutely free. That's also an axiom.
Some monitoring tools provide you performance profiling features, allowing you to identify and disable slow sensors. Ironically enough, MSI AB contains the most detailed monitoring performance profiler but it still gets hate and blame from "knowledgeable" users due to such clickbait videos.

I get why they're doing it - to be more user-friendly. Just install and bam it's working straight away. However, I do think things can be done better by showing more information inside the software itself about potential performance hits and whatnot(maybe even an optional set-up guide of sorts from the developer themselves to get the most out of the software). I've been using Afterburner for a very long time but never knew there was a built-in performance profiler, until a few days ago. They are user-friendly enough to provide quick and easy out of the box monitoring but not user-friendly enough to be transparent about possible issues like polling slow sensors or setting things up properly. Much is still either hidden or not there to begin with. I can say that I do really like the mouse-over explanations in RTSS though even that could be done in a more user-friendly way.