Re: Using FreeBSD to burn in computers

2004-01-21 Thread Dan Pelleg
Thane Sherrington [EMAIL PROTECTED] writes:

 I'm new to this list, and I'm not a Free-BSD wizard by any means, but for
 some time we've been using FreeBSD to burning new systems and to test
 systems for stability issues.  Below is the procedure we've been using.  One
 problem we seem to be having now is that if we run top while the various
 makes are running, we don't appear to be filling the RAM, so I'm looking for
 a way to stress the RAM more completely.  If people would like to take a
 look at the procedure below and comment on it, I'd really appreciate it.
 Using this system has allowed be to find problems quickly that other
 diagnostic procedures take days to find.
 
 

[...]

 d)type shutdown -h now to restart (I've no idea if this is necessary, but
 coming from the Windows world, I reboot after most installs.) :)
 

Definitely not necessary.

 
 5)Running the makes
 a)cd /usr/src
 b)make world; make world; make world; make world; make world (my idea here
 is to run make world and make on XFree86 concurrently, thus stressing the
 system further - I'm not sure if this is a good idea or not, but I'm sure
 someone will correct me.)


Have make start up many compiles in parallel with the -j switch: for
example make -j3. My rule of thumb for a most-effective make is 3 times
the number of processor. You will probably want a higher number just so
the strain on memory and disk is higher.

 
 c)cd /usr/ports/x11-servers/XFree86-4-Servers
 d)make (it will tell you it doesn't have all the files, and will download
  [...]
 d)cd /usr/ports/x11/kde3
 e)make (it will tell you it doesn't have all the files, and will download
 

These are fairly big packages, and you're downloading them from sites
operated by mostly non-profit organizations. To save on their bandwidth and
costs, you should really make a local copy of the distribution files. An
easy way to do this is to do a make fetch on one machine, which you keep
up and exporting its /usr/ports/distfiles over NFS, and have all the other
machines mount that directory over NFS.

 This tests the power supply, motherboard, CPU, RAM, hard drive (not
 completely of course), CDROM, and NIC.  So any failures that crop up after
 this are probably due to video or the windows software issues.
 
 
 Please feel free to critique these steps and point out what I'm doing wrong
 - I'm sure it could be improved a lot.

There's a whole set of special-purpose programs in ports under benchmarks,
but I assume you're already familiar with all of those which matter.

Here's an idea - try and look at the tuning(7) man page, and apply every
suggestion in reverse. I'm half-joking, but things like turning off
softupdates should really increase the number of disk accesses.

-- 

  Dan Pelleg
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Using FreeBSD to burn in computers

2004-01-21 Thread Dan Pelleg
Thane Sherrington [EMAIL PROTECTED] writes:

 I'm new to this list, and I'm not a Free-BSD wizard by any means, but for
 some time we've been using FreeBSD to burning new systems and to test
 systems for stability issues.  Below is the procedure we've been using.  One
 problem we seem to be having now is that if we run top while the various
 makes are running, we don't appear to be filling the RAM, so I'm looking for
 a way to stress the RAM more completely.  If people would like to take a
 look at the procedure below and comment on it, I'd really appreciate it.
 Using this system has allowed be to find problems quickly that other
 diagnostic procedures take days to find.
 
 
 T
 
 1)Download FreeBSD 5.1 (I don't know if this is the best version, since 4.8
 is the current stable release, but that's what I'm using.  I downloaded
 the large first CD, but I've been told I only need the mini, so I'm
 downloading that now and am switching to that.  You will need more than one
 computer to test this on, because I have gotten corrupted ISOs a couple of
 times on FreeBSD downloads, so you need more than one computer to check to
 see if it's an ISO issue, a bad CD, or a probem with the computer.)
 
[...]
 
 3)Get cvsup
 a)Type sysinstall (perhaps you can do this step without exiting sysinstall
 in the above step, but I like to go out and do a ping to be sure things are
 working.)
 
 b)Choose Configure
 c)Choose Packages
 d)Choose FTP
 e)Choose Site (I use Primary)
 f)Click Yes to the Network question
 g)Choose Net
 h)Choose cvs-without-gui
 i)Choose Install
 j)Choose Ok
 k)Exit
 l)Exit
 m)type shutdown -h now to restart
 

Another option is to download the full ISOs and install things from the
CD. Yet another is to run your own local FTP server, and choose that in
(e).

 4)Running cvsup
 a)Login as root
 b)cd /usr/local/bin
 c)cvsup -h cvsup5.freebsd.org /usr/share/examples/cvsup/ports-supfile
 Let that run (about 10-15 minutes in my experience.)

Again, this uses expensive bandwidth which can probably be put to better
use. See the handbook on how to run your own cvsup server, and use that for
the -h switch. (If you feel really generous, you could even make it public
so other people can cvsup to it).

However I'm not sure this step is necessary at all. You're installing the
basic tree in step (2) anyway. This cvsup will only update the ports to the
newest versions, but you're not really interested in *running* them
anyway. It can even incorporate a newly-added bug (sometimes the ports fail
to build because of problems in the makefiles, and if you're unlucky you'll
cvsup that just before the problem is fixed). I would just skip this
altogether.

-- 

  Dan Pelleg
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Using FreeBSD to burn in computers

2004-01-21 Thread Joerg Pernfuss
On 21 Jan 2004 09:20:20 -0500
Dan Pelleg [EMAIL PROTECTED] wrote:

  [...]
  b)make world; make world; make world; make world; make world (my
  idea here is to run make world and make on XFree86 concurrently,
  thus stressing the system further - I'm not sure if this is a good
  idea or not, but I'm sure someone will correct me.)
 
 
 Have make start up many compiles in parallel with the -j switch: for
 example make -j3. My rule of thumb for a most-effective make is 3
 times the number of processor. You will probably want a higher number
 just so the strain on memory and disk is higher.

For his purpose of stress testing the memory:
make -j64 buildkernel

I use this on dual proc boxes, maybe -j32 is already more than enough
for a single cpu.

Won't work with less than 128MiByte RAM iirc, but so far I haven't seen
something different that puts that much stress on your memory.
Surviving this two or three times in a row you can label your RAM
`non-faulty'.

Joerg


pgp0.pgp
Description: PGP signature


Re: Using FreeBSD to burn in computers

2004-01-21 Thread Jeremy Faulkner
Joerg Pernfuss wrote:
On 21 Jan 2004 09:20:20 -0500
Dan Pelleg [EMAIL PROTECTED] wrote:

[...]
b)make world; make world; make world; make world; make world (my
idea here is to run make world and make on XFree86 concurrently,
thus stressing the system further - I'm not sure if this is a good
idea or not, but I'm sure someone will correct me.)


Have make start up many compiles in parallel with the -j switch: for
example make -j3. My rule of thumb for a most-effective make is 3
times the number of processor. You will probably want a higher number
just so the strain on memory and disk is higher.


For his purpose of stress testing the memory:
make -j64 buildkernel
I use this on dual proc boxes, maybe -j32 is already more than enough
for a single cpu.
Won't work with less than 128MiByte RAM iirc, but so far I haven't seen
something different that puts that much stress on your memory.
Surviving this two or three times in a row you can label your RAM
`non-faulty'.
Joerg
Or he could just use memtest (ports/sysutils/memtest)

--
Jeremy Faulkner http://www.gldis.ca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]