MSI AfterBurner Shuttering When Fan Speed Changes

Nobody. Never. Read. Anything. Can this be fixed? Hope so. Is it so hard to peek into context help of the option you're about to use to understand what to expect after enabling it?


Fan speed update period

Displays and adjusts fan speed update period for user defined software automatic fan control mode.

Hints:

- User defined software automatic fan speed control is not absolutely free in terms of performance, some CPU time is required on each fan speed update iteration to read temperature from hardware and update fan speed if necessary. Depending on GPU and sensor model and hardware access protocols, software automatic fan control related performance hit can vary from virtually invisible to noticeable periodic performance hit causing an effect of stuttering in applications intensively using CPU, such as 3D games.
If you are facing such effect while MSI Afterburner is running, try to temporarily disable software automatic fan speed control to identify it as a problem source by unpressing the <User define> button. Then try to decrease CPU load by increasing fan speed update period.
Experienced users can also show performance profiler status information in the monitoring window by right clicking it and selecting the <Show status> command. Status information displays CPU usage times for different background processes including fan speed update.
- You may disable user interface tooltips via <User interface> tab in advanced properties.


Want it to be improved and eat less CPU time - spam nice AMD driver team and ask to optimize their fan speed control routines. But the chances to get any improvements from AMD side are close to zero.

 

Probably because ATI devel is a complete disaster when it comes to solving some issues and their programmers code worse than the students coming to take programming practice in my company? Like it or dislike it, it is a fact. The amount of time invested into different workarounds, added to Afterburner just to bypass issues caused by ATI's OWN drivers is already comparable to whole Afterburner project development time.
Probably you just have to try to work yourself with ATI and NVIDIA devrels to feel the difference and to compare level of techsupport provided by both sides?
For example, wanna know the story of voltage control implementation on the last generation hi-ends on both sides (Cypress and Fermi families)?

Cypress family:

We contacted AMD during implementation of voltage control on 5xxx series in a few weeks prior 5xxx announce, because we tried to implement the safest collision free I2C access layer and their own API for accessing I2C bus in ADL SDK for the Catalyst driver was not working at all. All they did was giving some flexible anwers about "probably it is locked in BIOS" or "probably it is not supported for some ASICs" and ended by sending us absolutely useless sample code for accessing DDC (which is pretty useless because VT1165 resides on alternate non-DDC I2C bus on Cypress anyway). And I2C routines are is STILL not working in AMD driver for Cypress. As a result, ANY low-level monitoring tool working with VRMs on Cypress, comes with its own I2C bus driver and have a great risk of causing VRM to enter wrong voltage state due to I2C access collision (try to google and serach for 1.6+V Cypress issues when running GPU-Z+Everest or Everest+Afterburner and so on). All that could be avoided if AMD invested at least a bit devrel resources into polishing the API they provide to developers. Most of issues reported to ATI never gets investigated and fixed. And unfortunately most of developers have the same impressions about it.

Fermi family:

NVIDIA themselves contacted all known hardware tool developers prior to launching Fermi and suggested everyone to rely on their own NVIDIA API for voltage control instead of direct access to VRM via I2C to provide the maximum safety to users. I faced small issue with voltage control, becaue there was no way to determine default voltage with the interfaces they provide (and as many Fermi users probably know, the chips have personal fused voltages so the hardware database approach doesn't work well) and contacted NV. Got an immediate reply, NVAPI is already being modifyed to provide this functionality. Most of issues reported to NV by their partners get investigated and fixed almost immediately after reporting.

It doesn't make any sense only for those who never tried to use any ATI routines and have no chances to feel how slow they are.

Yes, I'm saying that almost everything that ATI provides in ADL SDK cannot be used in realtime monitoring because it is terribly, drastically, insanely slow for realtime usage. I've already spent enough time to get rid of any ADL SDK calls in monitoring part of Afterburner because of that. Wouldn't like to do the same with fan control part, it will rely on AMD driver only (to provide maximum compatibility) and it will be as "effective" nice AMD can implement it.
And seriously, guys, you have a good reasons to think why there are so many "TWIMTBP" logos in games. That's not a question of money, that's a question of choosing a side that can provide proper support.

P.S. In the latest OSD server version I mentioned that new 3D OSD rendering mode gave drastical performance boost on the systems with ineffectively optimized 2D framebuffer access routines in the DirectX driver. Try to guess which driver was that?

 

It makes no sence if you discuss the things you don't understand at all. Does the "call latency" tell you anything? It is enough to a waste 50-100ms per driver call to waste CPU time comparable with frame time. It is enough to have such ineffective just call once per second to see a stutter in the game giving stable framerate. You will NEVER see such things on CPU load graphs. Start thinking please.

Really? Try to search this forum for stuttering issues with ATT if ATI driver is used just for software clock reading for example (this thing implemented at low-level properly takes less than a microsecond, ATI managed to provide interface doing the same 30x (!!!!!!) times slower). And if you're so stubborn, try to disable low-level monitoring part in Afterburner by adding LowLevelMonitoring=0 line to the [Settings] section of hardware profile file and feel the real power of stuttering caused by ATI driver's realtime thermal, clock and fan speed monitoring. These are the interfaces, initially designed by them for realtime usage. Beyond of my understanding how they managed to implement it so ineffectively.
And please no need to tell me that other tools don't face ATI issues, we're fighting endless ATI related problems in cooperation with many developers, including Ray. So you're either deeply misunderstanding things or simply lying.

One more such statement and you'll get permanent ban for spreading lie because of fanATIsm. I'm getting more that enough insults from both ATI and NVIDIA fanatics when their idol's balls are kicked. Got more tahn enough crap from NVIDIA fanboys when I declared than overclocking is broken in 196.21 WHQL, got more than enought "that's not our perfect NVIDIA drivers, that's third party crap like RivaTuner" from NVIDIA fanboys after declaring that fan control was broken in 196.75. But due to some odd reason NVIDIA prefer to intensively _monitor_ such issues and react immediately (overclocking issue was fixed in one day after reporting, driver with fan issue was pulled down almost immediately after report too) and ATI prefer to sleep ingoring the problems for ages. That's nobody's problem but their own.

So search for another place please for holy wars, this subforum is definitively not a best place for "ATI/NVIDIA rulez just because I own ATI/NVIDIA hardware" styled fanboyism. That's the first and the last warning for you and everyone.

 

Don't play the fool. It is enough for a ban to make ATIvsNV holy wars here and spread the lie about "publicly critisise one company all the time while ignoring problems with the other company" just to protect your idol. And both NVIDIA and ATI fanboys will treated this way. End of story, thread closed.