Excellent Stability Test

OS / Drivers / BIOS
Post Reply
phaedrus
Posts: 75
Joined: Tue Jul 20, 2004 11:27 pm
Location: Seattle, WA
Contact:

Excellent Stability Test

Post by phaedrus »

Linux offers an excellent hardware stability test. If you've modded your mobo (say, OC'd your celerons something high or slapped some PIIIs in there) and you want to know if you've got hardware instabilities to work out, this is it. It's really simple. Compile the Linux kernel. It's that simple. It takes 10 minutes even on fast dual processor machines (up to many hours on older machines, 386s were fabled to take _days_ to recompile the 1.x and 2.0.x kernels). It hits most of the salient points, it's heavy on the processing, memory access and disk I/O. It's better than the Quake test--all the software involved (make, gcc, the kernel source) is extremely stable and known to work (use a stable kernel release, they should _always_ compile cleanly), whereas Quake and other 3D games have bugs (so you can't rule out software), they rely on complicated video card drivers (also, often buggy, and the games usually sus out the bugs better than anything else). In short, you can rule out software with a kernel recompile, where you can't with most anything else.

So, how does it work? Boot the machine, configure and compile a kernel. The harder you want to test the machine, the more things to turn on (you don't have to ever run the kernel, just compile it). I usually do kernel compiles without Xwindows running. Nothing says you can't have X running, the kernel compile gets more processor time if you have less stuff running (and X is big, KDE and Gnome are outright). If you do this from an xterm in Gnome or KDE, it will just take forever, that's all.

If your machine is stable, it will make it all the way through. You can reasonably expect crashing is not due to hardware issues if it will compile the kernel.

If it fails (and it should do so spectacularly), note where it fails and try again. If you're using a stable kernel, it should fail in a different spot--if so, you've got hardware stability problems. If it fails in the same spot everytime (do more than two tests on this one), something in software is wrong (which means you likely did something wrong...).

One more tip: use

Code: Select all

make -j3 <target>

when compiling on your BP6 (the -j option tells make to split off multiple jobs, in this case 3 at time, to make use of parallel processing capabilities--you've got two processors, right?). Things will go faster, and you'll hit your system harder, as well as test the multiprocessing. You can also do this for a speed boost when compiling anything from source.

Jeff
"If it ain't broke, mod it till it is"
They said... and now my BP6 needs new processors... D'oh
Slackware Linux v10.1
Image
davd_bob
Confused
Posts: 1043
Joined: Fri Feb 13, 2004 2:30 am
Location: Houston, TX

Post by davd_bob »

I have Red Hat 6.x at home. When I get my BP6 back from Abit I will load it with (RH6) then do this compile test. I will test for stability first. If stable I am curious as to the mutliplier.

Is more clock ticks better or worse then less clock ticks to get the same MHz. Here is the test:
1) dual 366@550 - 100FSB
2) dual 500@540 - 72 FSB
3) dual 366@396 - 72 FSB
Of courst the 366s have a 5.5 and the 500s a 7.5 multiplier. The test is supposed to test the CPUs but I guess there will be a FSB corralation somewhere.
Purrkur, any projection on how the results will turn out?
There are *almost* no bad BP6s. There are mostly bad caps.

No BP6s remaining
Athlon 2800
Sempron 2000
ViaCPU laptop with Vista.(Works great after bumping ram to 2Gig)
P-III 850@100
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

There are also many different programs around in Linux for stresstesting hardware (not to be confused with benchmarking software). For example, memtest86 is a great little application that will test every dirty little corner in your computers memory. It is the best memory checker I have ever used and if your memory is giving up on you, memtest86 will find out.

For stressing CPU's, I found this little application in Debian called CPUburn. The description of it goes like this:
Description: a collection of programs to put heavy load on CPU
CPUburn is a collection of programs to put heavy stress on CPU.
These programs are designed to load x86 CPUs as heavily as possible
for the purposes of system testing.
.
Warning: The goal has been to maximize heat production from the CPU,
putting stress on the CPU itself, cooling system, motherboard. This
may cause data loss (filesystem corruption) and possibly permanent
damage to electronic components. Use at your own risk.
As you can see from the description, these programs mean business. I have never used them though because I have never needed to specifically stresstest a CPU lately. I will usually find out if CPU's are not doing fine if something unexpected happens during kernel compile like phaedrus mentioned (although my OC'd XP2400 will do that in a matter of minutes which is not long enough to lift problems to the surface).
davd_bob wrote:I will test for stability first. If stable I am curious as to the mutliplier.

Is more clock ticks better or worse then less clock ticks to get the same MHz. Here is the test:
1) dual 366@550 - 100FSB
2) dual 500@540 - 72 FSB
3) dual 366@396 - 72 FSB
Of courst the 366s have a 5.5 and the 500s a 7.5 multiplier. The test is supposed to test the CPUs but I guess there will be a FSB corralation somewhere.
Purrkur, any projection on how the results will turn out?
Yeah, in terms of what will compile the kernel fastest, I would say that the 550MHz speed will be on top. No doubt about it.
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Post Reply