Please register or login. There are 0 registered and 378 anonymous users currently online. Current bandwidth usage: 326.30 kbit/s October 01 - 10:26pm EDT 
Hardware Analysis
Forums Product Prices

  Latest Topics 

More >>


  You Are Here: 
/ Forums / Videocards /

  GPU Fan Speed controller alternative to Catalyst? [SOLVED] 
 Date Written 
Reason Oct 01, 2013, 03:26pm EDT Report Abuse
Running an MSI FrozrII 6870. Idles around 70C, and the fan speed is reported at 30%.

If I manually increase that to 50%, the temp drops to 55C with no perceptible/objectionable increase in noise.

When gaming, of course the temps increase, but (when set to Auto) the fan speed always seems to be too slow to compensate for the heat generated. I've topped 104 in Furmark, before I researched fan speed.

I can set profiles in CCC, and select them at will, but I'd prefer to have the ability to get the fan to go faster, and do so automatically. Ideally I'd be able to set thresholds: when temps are at X, fan speed doesn't drop below X%, for high and low values.

Anyone know any software that will help me achieve what I want? Looks like there are few out there, but I'd prefer to read someone else's experience before going through a bunch of install and uninstall cycles.


Ultima Ratio Regum
Want to enjoy fewer advertisements and more features? Click here to become a Hardware Analysis registered user.
Reason Oct 01, 2013, 08:39pm EDT Report Abuse
>> Re: GPU Fan Speed controller alternative to Catalyst?
Looks like MSI Afterburner does exactly this. The user-defined fan control lets you set a curve. Pretty sweet.

Ultima Ratio Regum
~Vel Oct 02, 2013, 02:44am EDT Report Abuse
>> Re: GPU Fan Speed controller alternative to Catalyst? [SOLVED]
Obviously late but I also endorse Afterburner. It's also useful because it monitors GPU usage so you can see if your GPU is bottlenecking you or not.

john albrich Oct 02, 2013, 07:53am EDT Report Abuse
>> Re: GPU Fan Speed controller alternative to Catalyst? [SOLVED]
You may also want to consider a redundant fan speed and/or CPU/GPU monitoring program, to provide an alarm just in case Afterburner (or other control program) glitches or even totally locks-up...even if you're using a quality controller program.

Any software/firmware-based control program may "glitch" or totally fail for a number of reasons, and a "second opinion" on the monitored/reported data is desirable...and user-definable alarms (e.g. Vcpu>60C, FANcpu<1000RPM, etc) even more so.

For example, I've had a software control program fail to keep a CPU fan running, and was only warned by the secondary monitoring program that the fan's RPMs had fallen to 0 and stayed there.

In some cases, a BIOS routine not only controls a parameter, but has a separate routine you can enable to provide an firmware-monitored alarm for some or all software controlled temp and speed parameters.

In other cases, usually the cheaper motherboards, you can use an application program like HWInfo32 (or 64), Open Hardware Monitor, Speedfan, etc. (unfortunately, I've noted that both HWInfo and OHM can provide highly intermittent, single event false readings that can set off a user-defined alarm. For example, if you monitor Vcore and set it to alarm at below 0.5volts, both HWInfo and OHM may, over a period of days report a single false reading of something like 0.016v...and will alarm if you have that option enabled. I think such false-positives result primarily because many of these monitoring/alarm programs don't use multiple-interval sequential values criteria(1) (I consider this a design flaw, as I believe motherboard data are occasionally misreported (aka a "glitch"). I suspect the primary cause of this kind of glitch is a higher-priority hardware interrupt that interferes with proper monitoring program operation.) However, I've never seen a false alarm from speedfan, but it's a much more complicated program for users to learn and operate correctly. With some of these monitoring programs, an alarm/alert can be sent via an email, a motherboard "beep", playing a user-defined sound file, opening an alarm "window", providing a system tray alert "pop-up", or any combination of the above.

Watch out for control conflicts. If you use a secondary monitoring program and it also has parameter control functions, make sure you don't have any parameter control conflicts (e.g. use only the monitoring capabilities and disable the control features of the secondary program). Same thing for firmware-based control capabilities.

(1) Difference between single interval and multiple interval based alarms
A single interval based alarm will alert on the basis of even ONE "out of bounds" reported value. For example, let's say you're monitoring a fan RPM at 1second intervals. A single interval based alarm will alert if any single measurement out of thousands of seconds of samples is out of the user-defined bounds. That means a fan running at 1000RPMs for hours, and then has a SINGLE 0RPM reading, and then reports 1000RPMs for the rest of the time, will still alarm because of that 1 glitched 0RPM reading. A multiple interval based alarm will alert only if N sequential intervals sampled are out of bounds (e.g. the monitoring program would have to "see" N seconds of 0RPMs before an alarm is posted). This significantly reduces the chance of an alarm due to a single (or N-1 sequential) mis-reported value due to a motherboard data reporting or monitoring program glitch.

Edit20131003: Note, I've also seen HWInfo32 have a random periodic very intermittent "Temperature 1"=193C (again, just a single reading every so often amongst thousands). "Temperature 2" also sees this anomaly but at completely different times compared to "Temperature 1". These were the default labels for 2 of the several temps being reported by HWInfo32 about the CPU. On the Gigabyte motherboard I'm doing this study, I think Temp1 is a case temp, and Temp2 is a core temp. As I've noted elsewhere, Vcore and Vccp2 also show occasional anomalous readings. Because of the (IMO flawed) single interval reporting algorithm, I suspect just about any of the parameters will eventually show an anomaly given enough time, depending on the motherboard used and computer activity.



  Topic Tools 
RSS UpdatesRSS Updates

  Related Articles 

A weekly newsletter featuring an editorial and a roundup of the latest articles, news and other interesting topics.

Please enter your email address below and click Subscribe.