On Tue, 2006-12-12 at 01:37 -0600, Mike McCarty wrote: > Les wrote: > > On Mon, 2006-12-11 at 20:15 -0600, Mike McCarty wrote: > > > >>Ed Greshko wrote: > >> > >>>Mike Chalmers wrote: > >>> > >>> > >>> > >>>>I like Linux, alot. I mean alot. I like what it stands for (besides > >>>>the corporations). But my CPU has never overheated. I am pretty sure > >>>>that it is not my hardware. It could be a bug in Linux. The kernel > >>>>could be be sending incorrect frequencies to the hardware or something > >>>>like that. > >>> > >>> > >>>Hummmm.... Something like that happened to me years ago... Let me think. > >>>Oh, right..... > >> > >>[snip] > >> > >>It is a well-known fact that faulty software can overheat CPUs. > > > > [snip] > > > > I do believe that I can cause some processors to overheat, however, that > > software would not do anything useful. Once you start accessing memory, > > Yes, it does. It searches for large prime numbers. That program has > found several largest known primes in the last few years. > > [snip] > > > The GIMP testing program I would suspect verifies such things as look > > ahead, que length call/return overhead and so forth to give a good > > "frames per second presentation" vs a temperature test of the processor. > > Actually, it doesn't. The point of it is simply to run as intensively > as possible, and see whether it can complete. If the CPU overheats, then > it doesn't work properly, that's all. It doesn't read any sensors. > > [snip] > > > > > As to the statement that faulty software could cause it, perhaps, but > > it would be a real fluke, because as I said lots of things get in the > > way in a real normal system. Such a software bug would have to disable > > lots of hardware besides the processor to create that kind of havoc. > > Eh? All it has to do is be constantly ready to run. If the process > never blocks for I/O, then it would keep the CPU pretty busy. > > Yes there would be breaks when other processes get time, possibly, > due to virtual misses. But that is by no means guaranteed. > > Mike > -- Hi, Mike, There is a lot about Linux I don't know. There is a lot of everything I don't know, but when it comes to IC's, including processors and how they work, there are not too many people I have to take a back seat to. Not as a designer, but as a test engineer with over 20 years experience and as a programmer with over 30 years experience. The most stressful program that you can write for a processor accesses only about 6 or 8 words of memory, and does that same act repeatedly with no branching. One is called the push loop, where an instruction for push a register and that register is placed on the stack using the push instrution, and this is followed with an instruction to decrement the program counter. Then the program counter is pointed at the push instruction and started. The system then pushes the register, and decrements the pc to point to the pushed instruction. In effect the program is push: jump push. Similar microcode exists in some processors where a compare can be done and set up the flags and a jump here on non-zero will enter an infinite loop. But these are special conditions, and require setting up the situation to that effect, and either one, if interrupted has the option of a return to the following address and will break the loop. They are tricks. But even these won't overheat a modern processor. What you need is a special instrucition that cycles all register contents, like a checkerboard and inverse checkerboard and does it rapidly. I won't even mention the required sequence because it is really hateful code. But it can be done, and a really artful programmer can probably even lock a cache containing processor into an infinite internal loop doing that, which coupled with turning off certain other processes and hardware could do the trick, but today a reasonably efficient Mother board with reasonable cooling will even handle this dastardly trick for quite a while. And again the thermal sensors will sense the condition and shut it down. There are some other hardware secrets that can prevent this type of action as well. These new processors are energy hogs, and some of that is reduced by the new lower voltages which drop the power curve in a linear fashion. Design cell size also will reduce transistor power and capacitive load, which is the real power hog in processor design. And modern design attempts to pattern the registers in such a way that the thermal cycle is managed as well as the electrical cycle. But still when you swap a million transistors from one state to another in pico seconds, you have a tremendous parasitic power exchange and thermal effects that result from that relative to the real estate and thermal constant of the packaging. It's a real handful. Intel, for all the flack they get has done their homework on this stuff, and the task goes up geometrically with each new generation of component. Doesn't answer your heat question, I know, but if the Mother board is designed correctly and the cooling is designed correctly, and work once, then the changes that typically cause problems are dust and dirt, mechanical failure (fan or loss of heat conductivity to the heat sink (compound dries up and falls from the two mating surfaces), or something physically breaks, like the wires to the fan. While software can affect the thermal load, the design criteria take that into account when the thermal package is designed, so under normal conditions, heating will not shut things down. As to the prime number algorithm, it ranges over many pages of memory and really is not an intensive program for calculations. The hardest program is a gausian filter on a 3d array, because of the local nature of operations and the number of operations done. Another good indicator of some of the effects are the response graphs given for the FFTW (Fastest Fourier Transform in the West). Check out how the flops fall off once the cache size is exceeded. I have considerable experience with FFT's as well. Regards, Les H
