Coming in late on this one, but what the heck. Might as well throw in my 2 cents on this…
Processors (not just the AMD Athlon/Duron, but that's what I'll stick to here) going way back (486 days) have been able to go in to an idle/suspended state, wherein they would consume less power and thereby produce less heat. But the processor does not go in to this state by default unless it's "told" to, even when it isn't specifically being called upon by the OS or apps running under it to do anything (execute instructions). And the way the processor gets "told" is basically one of two ways: 1) it receives the HLT (halt) instruction, or 2) it is put in to what's called a Stop Grant State via the motherboard chipset. Method "1" can be thought of as a front door method, while method "2" is kind of a back door method (at least for my thinking).
A (no so) quick note... There is an interaction/dependency that both methods are subject to in terms of putting the Athlons/Durons in to an idle state where power use (and heat generation) is reduced. To get in to this state the processor has to disconnect (not physically, just a communication state it goes into :)) from the system bus. But whether it can disconnect or not is controlled by a bit in a register in the chipset (northbridge). As long as the appropriate bit is enabled, regardless of the method used (1 or 2), the cpu can be put in to the desired idle (lower power/heat) state. If the bit isn't enabled then neither method will cause the cpu to go in to the desired idle state. With via chipsets of a couple years ago (via chipsets have been popular for amd based processor boards) the bit that had to be enabled was bit 7 in register 52. That's why people might have seen a lot of stuff written about register 52 and via chipset boards (the register can differ on newer boards). One of the issues is that whether this bit is enabled or not by default is controlled through the bios at startup, and a) not all bioses enable the bit, and b) what a bios/board maker does can change over bios revisions (eg. Asus did this and caused a lot of turmoil until people figured out what had happened) and between different boards. Why isn't the bit just enabled by default? In short, because there can be issues/problems caused by the bit being on. Whether this is the case or not depends on the particular motherboard, the settings in other chipset registers, things like particular add-on PCI cards in use, etc. So there are some tradeoffs that have to be made, and as a result a vendor may decide it is best overall to disable the bit the allows the cpu to disconnect from the system bus. All the Athlons/Durons are able to go in the (cooler) idle/suspend sate, if the chipset allows it to. So it's really a chipset (and motherboard maker) issue rather than an AMD issue as concerns the Athlons/Durons going in to the lower power and heat dissipation state. Anyway...
The software cooler programs around (like Rain, Waterfall, Cpuidle, or proprietary ones like PC Alert) rely on method "1" to provide extra cooling for Athlons/Durons. They rely on sending the CPU HLT instructions. To do this they create an "idle loop" (mentioned in the link Train gave) that runs whenever there isn't other (real) work for the cpu to do. With Win9x/ME OSes you need one of these third party software cooler programs to be able to provide extra cooling. With an OS like Linux, OS2 or one based on NT (NT, Win2k, WinXP) the operating system itself will generate an idle loop during times of no other work. So is it unnecessary to use third party software with these later OSes? Maybe, maybe not. If the bit (mentioned above) in the chipset register to allow the CPU to disconnect from the system bus is enabled by default by the bios or you enable it manually via a program to manipulate chipset registers (like one called WPCREDIT), then you don't need third party software coolers. Otherwise you have to take the extra step of enabling the bit (again, through something like WPCREDIT) or use a cooler program (cooler programs pretty much all enable this bit during their initialization).
When the "idle loop" method is used one of the things that can happen is that particular methods of displaying cpu utilization will show the cpu use at 100%, like Limerick saw. Is the cpu really 100% busy? No. It's shown that way simply because of the way the measurement is made. The amount of idle time is being monitored, but there is none because that time is being consumed sending HLT instructions to the CPU, so it "appears" as though the system is 100% busy. As I said though, it isn't.
As mentioned, the "idle loop" method is not the only way to achieve additional cooling with the Durons/Athlons. There's also the Stop Grant Method. The easiest way to use this method is to exploit the ACPI capabilities of the motherboard and OS. If you enable ACPI in bios, then have the OS enabled for ACPI, the OS (even a Win98/ME) will communicate through ACPI functions to the chipset to produce the Stop Grant State when there isn't (real) work for the CPU to do. You still, as mentioned, also have to have the appropriate chipset registry bit set to enable cpu disconnects, but… I tend to use this method with Win98/ME Instead of cooler software). I use WPCREDIT to enable cpu disconnects, and have ACPI enabled in the bios and Windows. I just let Windows (through ACPI) do its thing, and I get the additional cooling I want. Is this method better or worse than the "idle loop" (cooler program) method? No. I just prefer it. The one thing this method doesn't do (as opposed to the idle loop method) is cause cpu utilization to show at 100% all the time. Not a big deal though since, as I said above, this is a false display anyway.
Do using either of these methods to cool down an Athlon/Duron shorten the life span of the processor (due to the thermal swings caused). The short answer is yes. But the (IMHO) meaningful answer is not in any quantifiable (or more importantly) meaningful way that needs to be worried about. And I'm not aware of any evidence to the contrary. It is true that the thermal swings have an effect, but relatively speaking your likely looking at something like getting (being generous) getting 10 years from the processor verus maybe 15. You'll likely long since have stopped using your cpu before any effects are realized. Besides, cooling a processor extend its life, so there's a positive effect there (but don't bother try to quantify the realized gain here either). Bottomline: whether one of the methods talked about here to cool a cpu or not, either way I wouldn't worry a heck of a lot about the effects on life span.
Can there be other negative effects caused by using one of the cooling methods here? Like I said earlier, yes. Performance is not an issue though. Some argue that there are wasted cycles used to "wake up" the cpu (bring it out of its suspend/idle state). Paaaleeease! The cycles it takes are trivial. IMHO, there is no real, meaningful performance hit/issue (not anything anyone is going to really notice), certainly not in the general case. But there are, or can. be other issues. These generally are very chipset, motherboard and/or situation dependent. There can be system hangs, voltage issues/fluctuations, effects on PCI card function, etc. So in some cases it isn't always best to do any of the things mentioned here to try to cool your Athlon/Duron down a bit more (which, again, is why mb makers may choose not to provide the appropriate chipset register settings).
Well, I guess I put in more than my 2 cents after all. More like 50:eek:. Oh well, not sure whether this contributed anything here or not, but... Maybe just confusion.;)
