> It's not a cpu loader, no more than memtest86 is just a ram tester. > There's no way for any software program to separate the cpu/cache/ram > subsystem. If a system can run cpuburn (eg, 'burnk7' for an Athlon)
Well, looking at the burnK7 (or other portions of cpuburn) I was very skeptical as to how it could really stress the system, as it ks just a couple of floating point instructions in an endless loop. But from others' input, it seems to peg the cpu temperature meter pretty high, higher than i would think for such a piece of software. The loop is too short to not fit in cache (or probably the instruction pipeline itself -- that depends on the size, I'm not sure) and depending on CPU timing issues and stalls (usually affecting older Pentiums) it might not exercise the processor as much as is desireable. I ran across a similar burning type program (shareware) back in my DOS days - it was purported to be an industry-standard burn in tool, and said it was doing all sorts of complicated floating point operations, cubic splines, fast fourier transforms, and so forth. I'm not so sure that's all that better, especially given that dumb DOS compilers would insert fwaits before floating point instructions, and the coprocessor wouldn't get all that hot anyway :). > memtest86, might not pass cpuburn. It's an old overclocker's tool to > test for stability, been around for years. And hardware that passes memtest86 may fail in a stressful session with gcc. :( Memtest is sequential and performs a selected set of tests on the memory, but it can't (or doesn't) simulate the somewhat random-like access to memory that gcc does. Then again, gcc doesn't randomly 'walk' all over your whole memory space, but only a small subsection of it. > Tom Brinkman Corpus Christi, Texas
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
