Thanks Paul for taking the time to check this out, and post
your results!!!
I guess I just have to accept that once again, have ended up
with an ASUS board which has limited or no fan speed control.
Your info, at least, means I don't have to keep searching for
"better" software. No software will be able to control
the other fans.
It is interesting that ASUS features (pushes) Q-Fan as a way to
greatly reduce the fan noise in a PC. However, just controlling
the CPU fan, and NOT the case fans nor the power supply fans
will do very little to reduce the overall fan noise. Matter
of fact, I bet one can't even tell, noise wise, when JUST
the CPU fan is reduced in speed by 20%.
Ah, it seems that I have been spoiled by the old P3B-F which
allows me to control ALL the fans with SpeedFan.
I would have recommended a drive bay fan controller, but with
my lousy searching skills, all I've found so far, are the
manual style (Nexus) controllers. I thought there was at least
one product out there, that has thermistors for controlling
case fans.
The most important thing to provide air flow for in the computer,
is for the disk drives. They have the tightest environmental
requirements, and it would be best if inlet air is drawn across
them without mixing with the other case air. The rest of the
components can safely take a lot more heat, relatively speaking.
I just recently bought a P4C800E Deluxe (as I'm not interested
in LGA775 or PCI Express or processors with large DC leakage
currents that waste power not related to computing). I checked
with an ohmmeter, and the two other fan headers have their
+12V pin connected directly to the +12V pin on the ATX20 pin
connector. It would seem there is no controlling device in that
path.
If Q-Fan and Speedfan attempt to control the Winbond chip at
the same time, I think you can see there would be chaos. Only
one program should be writing to the fan control register at
a time, if you want consistent results. Also, from a monitoring
perspective, only one monitoring program (Asus Probe, Motherboard
Monitor, Speedfan etc) should be running at a time, as the OS
provides no semaphore for controlling access to the serial
SMBUS. That bus runs so slow (10KHz?), it is possible for one
monitor program to kick off a "read" op on the serial bus, and
then the OS can schedule the execution of the other monitor
program, which might just be about to do the same thing. An
interrupted read op, results in garbage data and a "spike" in
the smoothed results. (My theory is, it is not entirely possible
to eliminate this fully, as the BIOS is reading the registers all
the time too ?)
Paul