I have been watching this thread for a while now. I am surprised everybody
is happy with the temperature drops they get and don't look a bit
further. I might be sounding like a *ickhead but here go my .02 euros:
With STOPGNT enabled, the disconnection happens by the northbridge
actually halting the FSB for the CPU until the next interrupt. The
continuous dis/reconnection causes increased lattency on the PCI bus and
strictly timed PCI transfers needed by TV-Tuner cards/software or sound
software suffer greatly from this. It also results in poorer hd
performance.
Also with such a power hungry CPU as the Athlon, bus dis/reconnection
results in current demand changing from 40A to 5A to 40A ... every few ms.
This puts your motherboards' voltage regulator under unecessary strain as
well those in your PSU.
Furthermore, CPUs do like lower operating temperatures, but even more they
like constant temperatures. Differences like 10-15C every now and then
(load/idle) put the cpu die under mechanichal strain from thermal
contraction/expansion.
Finally, this procedure can actually *hide* severe cooling inefficiency of
the system. People seem to go with the moto: STOPGNT lowers my
temperature, so it is a good thing. Well, it doesn't. Run SETI@HOME and
you are back where you started. It can take only a hot summer day and you
have a fried chip.
There was a thought by somebody, that you should only enable disconnection
after some time of inactivity. This sounds better, but then, don't we
have S1/S3 for this already?
This feature of the AMD processors seemed like a real bargain once but
now, I doupt there is one motherboard vendor out there that allows you to
control it in the BIOS (like they used too). Even more, they suggest you
leave this feature alone. A walk in troubleshooting/support forums
suggests the same: It is a feature you can do without, you'd be better off
with a cooler that can cool and a well ventilated case.
Sorry for the length,
-Kostas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/