Re: cpu overheating

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux