Re: System Burn In
On 2/28/06, Nikolas Britton [EMAIL PROTECTED] wrote: On 2/28/06, Don O'Neil [EMAIL PROTECTED] wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. Maybe try http://www.holm.cc/stress/ but this would be like forkbombing. If the system locks it may be a kernel problem, not be a hardware problem. Check out UBCD, just type it into google. I did not have alot of time on hand the first time I posted this so let me go over it again. The main problem that Kris and I pointed out with using kernel regression testing tools is that by design the software is trying to crash the kernel. This is not so great when your testing for hardware problems. Solid state electronics will fail predictively and it will often be a complete failure in such a way that the system won't boot, you have POST errors, or a card or peripheral device just won't function correctly. This type of problem is test for before it leaves the factory. If you had such a problem it would become apparent in preliminary testing. If you can install FreeBSD and successfully complete a make buildworld session I'll put money down that you don't have this type of problem. This leaves four things to test for: memory, PSU, overheating, and mechanical failures. Overheating (and PSU): In a controlled environment overheating problems are predictable and can be directly measured. The primary goal is to get all heat producing componets at maximum output all at the same time and then use a DMM with a thermocouple to proble all the hot spots. a make -j4 buildworld session will stress the CPU, Chipset, and RAM but it won't stress the disk drives or the video card GPUs, I don't know how to stress the GPUs (If your you using them for vector computation). If you have a RAID array you will also need to find a method[1] to stress this because an 8 disk array can easily produce just as much heat as the CPU, if not more. RAM failures: problems with memory are random events. The only sure fire way to test ram modules without doubt is a hardware based ram testing device but if you get random buildword failures (use Kris's -j(N) to maxout main memory) it's a good bet that you have a bad ram module. PSU Problems: Like ram failures PSU failures are (semi-)random events and it's often difficult to tell which problem you have because they can both produce the same symptoms. rant Never skimp on a PSU!... I just can't understand why people would skimp on the most important part of a computer, without this device you have no computer and with a crappy one you have a crappy computer. Always buy the best and overspec it! /rant Doing the thermal testing (above) will also stress the PSU. If you have random reboots when thermal testing and your system is not overheating you may have a PSU problem. Mechanical failures (disk problems): Disk problems often have a bathtub curve[2] failure rate. If a disk has not failed in the first month of use and you protect it from overheating and G-force damage their is a high probability that the drive will hit and surpass it's MTBF estimate. I stress test all my drive using MHDD32[3]. It has a simple feature that will perform random seek access tests on the disk till hell freezes over, or the drive fails. I often just connect the drive, run the test, and let it do it's thing for a few days. After this is done I run a complete functional diagnostic test on the drive and pop it into the computer if it passes. It's also useful for producing random wear patterns on disks earmarked for RAID arrays. [1] Use something like iozone, in ports: benchmarks/iozone, http://www.iozone.org/ [2] http://en.wikipedia.org/wiki/Bathtub_curve#Bathtub_curve [3] You can find the MHDD32 utility on the Ultimate Boot CD (UBCD). -- BSD Podcasts @ http://bsdtalk.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Burn In
The motherboard manufacturer's usually have stress tests in their diagnostics. These usually run outside any OS, meaning you boot the diagnostics. Run them for a couple days continuously to show any issues that may occur. -Derek At 02:27 PM 2/28/2006, Don O'Neil wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Burn In
On Tue, Feb 28, 2006 at 12:27:07PM -0800, Don O'Neil wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. Doing something like a buildworld -j64 loop (if you have enough memory, otherwise reduce -j level to avoid swapping) is going to exercise your system a fair bit. Kris pgplvFNsTpJ3a.pgp Description: PGP signature
Re: System Burn In
At 02:27 PM 2/28/2006, Don O'Neil wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. a good test of network, motherboard, cpu, memory, and limited hard drive is to build world from scratch. if this completes successfully, you can be fairly sure everything is working properly. luke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Burn In
What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. look4 in /usr/ports/benchmark forkbomb, etc. Pol ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Burn In
On 2/28/06, Don O'Neil [EMAIL PROTECTED] wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. Maybe try http://www.holm.cc/stress/ but this would be like forkbombing. If the system locks it may be a kernel problem, not be a hardware problem. Check out UBCD, just type it into google. -- BSD Podcasts @ http://bsdtalk.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Burn In
On Tue, Feb 28, 2006 at 06:09:17PM -0600, Nikolas Britton wrote: On 2/28/06, Don O'Neil [EMAIL PROTECTED] wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. Maybe try http://www.holm.cc/stress/ but this would be like forkbombing. If the system locks it may be a kernel problem, not be a hardware problem. This is a bit hardcore, because as you note it sometimes finds kernel bugs so it's not going to be easy to identify the cause of problems. Kris pgpu9NAImSKzp.pgp Description: PGP signature
Re: System Burn In
Hello, Don O'Neil wrote: What is the best way to 'burn in' or 'stress test' a new system w/ FreeBSD? I'd like to stress test the CPU, Memory, Disk, etc.. To make sure the hardware is 100% good before putting it in production. You want to test hardware, not OS, so I would recommend you to use: http://www.ultimatebootcd.com/ Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
