NetPerf
I used to have this benchmark, but I don't any more. I should probably get it back and start doing some more with this. If anyone has RPMs of this already put together against a glibc system, feel free to drop me a line and let me know. I'll add them here and start using them to test some of these systems I end up testing.
 
LMBench
LMBench can be found at www.bitmover.com/lmbench. I sometimes use it, sometimes I don't. The last version I tried (lmbench-2alpha11.tgz) had a few bugs that kept me from getting the numbers I was looking for and didn't do all it was suppossed to on 2.2 linux kernels. I'm waiting for the actual 2.0 lmbench to see how it does. Note: Larry, it needs to do something with the FPU to test both lazy and unlazy context switches and the scripts need to support ssh programs as well as rsh programs are my two biggest complaints.
 
TTCP
TTCP is a basic network speed tester. It really only pumps data from one side of a TCP/IP network socket to another as fast as possible. The numbers this gives aren't really intended for any type of mass consumption other than as some sort of base guideline to how well your TCP stack can fill the particular pipe it is talking through. On modern machines, the bottleneck usually isn't the CPU, so those measurement becomes almost dubious at best. I primarily use this as a means of testing reliability. This will generate a lot of TCP packet allocations/deallocations and network card interrupts, so it's usefull in determining if your ethernet card driver is reliable or if it might break under heavy load.
 
ttcp-1.4-1.i386.rpm
ttcp-1.4-1.src.rpm
 
iotest 3.1
Iotest is designed to mainly work random disk reads and writes. It wants access to a raw device or a whole disk partition. It is menu driven and fairly easy to use. It also uses large numbers of threads to be able to start and run lots of seeks per second. It should do a good job of keeping the disk subsystem filled with requests. For now you can get the test from this site, as I can't remember the URL to get it from the main site (it's probably in the tarball somewhere, but I don't want to look for it right now). If someone wants to make an RPM out of this, please let me know and I'll put it up here instead of the tarball.
 
iotest31.tgz source code tarball
iotest documentation (pdf)
iotest changes from 3.0 to 3.1
 
dt
This is likely the best disk/scsi test program in the bunch. It stands for "data test" and it does more things than any of the other programs here. It isn't really a benchmark program as much as it's a data integrity testing program. However, it can also be used to benchmark things as one of the intended roles of this program is to help people tune their drivers once they have already verified that the driver is reliable. I won't spend much time describing it, instead, I've got the documentation URL below. The docs are in Postscript format and are ready for printing. There is roughly 50 pages of docs here to go through, that should give you some idea how much this suite does.
 
Users guide
Source code
 
Bonnie
Bonnie is a disk benchmarking program. A person should always understand what a benchmark number means in the real world. Bonnie gives back 6 different numbers. These numbers are Block Reads, Block Writes, Character Reads, Character Writes, Re-Writes, and Random Seeks.
 

• Block Reads/Writes:
  In these test, bonnie tries to read a file it has already written in blocks of 8k at a time. It doesn't do anything usefull with the data it reads, it just sucks it in and then sucks the next block in when that's done. This gives some sort of indication how fast the OS is at sequential disk reads. Keep in mind that this is a regular file read through the filesystem. No Async I/O and no Raw Disk I/O is being done here. As a result, don't try to compare these results to the disk read results from something like IOMeter under Windows NT. They are testing two totally separate things (IOMeter uses Raw I/O and Async I/O under NT to get its speed, which totally bypasses all the filesystem layer entirely and only tests the speed of the disks and controller). By going through the filesystem, you get a closer to real life metric since we end up seeing just how fast a normal application can expect the OS to be able to feed it data. Most apps are not Async I/O and Raw I/O aware and won't be able to muster the numbers that IOMeter would suggest. Eg, Microsoft Word under Windows NT does *NOT* use Raw I/O and Async I/O so the numbers you get from Bonnie would be a closer approximation of how fast NT could supply a large file to Word than are the numbers from IOMeter. The exact same things are true for the writes.
  
• Character Reads/Writes:
  In these tests, Bonnie writes to or reads from the file one byte at a time using either getc or putc. In general, reading a file one byte at a time is stupid and useless. In specific, reading a file one byte at a time is stupid and useless :) In this case, the only thing you are really testing is *not* your OS. Instead you are testing the speed of your libc library. Since how the libc library implements the buffering of these single byte requests and how efficient it is outside of that will determine the speed of this test. Under linux, the speed of putc/getc is also drastically effected by whether or not you use the thread safe version :) When using glibc-2.0 or later, using the putc_unlocked() and getc_unlocked() routines will greatly improve performance on these tests.
  
• Re-Writes:
  In this test Bonnie reads an 8k chunk of data, modifies one byte, then writes that 8k chunk back to the original file. This tends to stress your OS's filesystem code quite heavily. The filesystem has to continually update data blocks on the disk or reallocate blocks on the disk, etc. It also stresses how well the OS caches data. This would most closely approximate what a smaller SQL database would be like during update phases (it doesn't even begin to tell you anything about databases like Oracle that want access to plain raw devices and no OS intervention in their read/write patterns, only in smaller databases that utilize plain files to store information in).
  
• Random Seeks:
  This test provides a reasonable clue as to how well your OS orders the requests it gets. This test will randomly seek into the file that was written and read a small block of data. The more of these you can complete per second, the faster your OS is going to be when performing real work. Since the biggest bottleneck to hard disks is not the actual disk throughput but instead is the disk seek times, better numbers here will mean better performance overall. This is especially true when dealing with more than one user banging on a machine at any one point in time.
  

 
Bonnie hasn't been updated in a long time, but I have a version that I use here. This version of bonnie was compiled against glibc-2.0 on a stock Red Hat Linux 5.2 system with the unlocked putc and getc routines and an additional patch by myself that I use for kernel performance analysis (if you pass the -p switch and are running a linux kernel with performance profiling enabled, then bonnie will save multiple files in the test directory with names like Bonnie.215-getc, each one of which is a specific profile of the kernel during that portion of the bonnie testing and will tell you where the kernel spent its time during those portions of each run).
 
bonnie-1.0-6.i386.rpm
bonnie-1.0-6.src.rpm
 
 
 
If people think I should start using some other benchmarks and can provide some reason for believing so, then I could probably be persuaded to do the extra work and get some results out on various systems. I wish I had the client machines to do thinks like webbench or netbench, but that won't happen I'm afraid. That requires way too many resources in terms of client loading. But, if I can get Red Hat talked into setting up a lab with enough clients and I can carry some of these wazoo boxes up to that lab....