Disk Test & Health Monitoring

By default only a non-destructive read-only test is done.

Badblocks needs memory proportional to the number of blocks tested at once, in read-only mode, proportional to twice that number in read-write mode (NB, might not be true. I noticed that the memory requirement is constant, as in e2fsprogs-1.27-9. Tong), and proportional to three times that number in non-destructive read-write mode.

If you set the number-of-blocks parameter (-c) to too high a value, badblocks will exit almost immediately with an out-of-memory error "while allocating buffers" in non-destructive read-write mode.

If you set it too low, however, for a non-destructive-write-mode test, then it's possble for questionable blocks on an unreliable hard drive to be hidden by the effects of the hard disk track buffer.

http://www.debian-administration.org/users/Grimnar/weblog/27#comment_5

With drives disappearing/reappearing I'd be tempted to say you have a pending drive failure, or other hardware problem.

Run dmesg and look for disk errors with something like this:

Steve

I agree with Steve, above, about pending (or existing) disk failures. You might want to look into the smartmontools suite as well. You can schedule tests for your disks, and query them directly about their status.

write back with any info from smartctl when you've got it.

to run a bunch of short tests on all your disks, just do:

There should be some messages printed about what time you should expect the tests to complete. once the tests have completed (probably 5 minutes max for most short tests, but depends on the disks), you can read the info with:

You should then be able to read the diskreports.txt file to see what the disks have to say for themselves.

For a single disk, of course, the commands are even simpler:

documented on: 29 Sep 2007, dkg

documented on: 2008-03-29

Solve the problem why smartd daemon failed to start.

The device /dev/sda is actually SATA disk.

Need to add "-d ata" to /etc/smartd.conf

Although it is OK to omit the '-d ata' switch from 'smartctl' command:

in daemon config file, the '-d ata' switch is still necessary.

documented on: 2008-03-29

Doesn't look good whatever it is. Hope you have a good reliable backup.

This doesn't sound good either.

See man smartctl. You run a '-t long' test on the drive which will tell you how long the test will take. Wait at least that long and use smartctl to check the results. Ideally "completed without error" but you will also get a list of all smart parameter values so you can see how things are going.

NB: if SMART says that the drive is failing believe it. If SMART says that the drive is fine, look further. Check the drive temp, listen to it, watch those errors. Given those errors, I'd be checking the warranty on the drive.

Doug.

Douglas A. Tutty @porchlight.ca

Don't know about ide-smart, but I've had drive issues too and use smartmontools now. I configured the demon to issue short self tests daily and a long one once a week with an entry like this in /etc/smartd.conf:

Apart from that, i have a cronjob to daily mail me the output of smartctl -a /dev/hda

That output contains all the drive status params smart can gather, like

Now, here you'll want to watch the Pre-fail attribute counts, since, as their type suggests, they tend to (rapidly) increase before a failure. In all my disk issues this has been particularly true for Raw_Read_Error_Rate, so I watch that one closely. Small values like 3 or 10 are OK, but rapid increase over a couple of days to hundreds or thousands means the drive is about to die, typically during the next one or two days. Single blocks may already be unreadable at that point, so backup the drive immediately.

Note that even in that case, smart might still say the drive PASSED the self test, so a PASS should not really comfort you. It definitely makes sense to check the status attributes yourself.

Bruno Hertz

Extracted from

To understand how smartmontools works, it's helpful to know the history of SMART. The original SMART spec (SFF-8035i) was written by a group of disk drive manufacturers. In Revision 2 (April 1996) disks keep an internal list of up to 30 Attributes corresponding to different measures of performance and reliability, such as read and seek error rates.

Each Attribute has a one-byte normalized value ranging from 1 to 253 and a corresponding one-byte threshold. If one or more of the normalized Attribute values less than or equal to its corresponding threshold, then either the disk is expected to fail in less than 24 hours or it has exceeded its design or usage lifetime. Some of the Attribute values are updated as the disk operates. Others are updated only through off-line tests that temporarily slow down disk reads/writes and, thus, must be run with a special command. In late 1995, parts of SFF-8035i were merged into the ATA-3 standard.

To make use of these disk features, you need to know how to use smartmontools to examine the disk's Attributes, query the disk's health status, run disk self-tests, examine the disk's self-test log (results of the last 21 self-tests) and examine the disk's ATA error log (details of the last five disk errors).

To begin, give the command

If SMART is not enabled on the disk, you first must enable it with the -s on option. You then see output similar to the output shown in Listings 1-5.

The first part of the output (Listing 1) lists model/firmware information about the disk — this one is an IBM/Hitachi GXP-180 example. Smartmontools has a database of disk types. If your disk is in the database, it may be able to interpret the raw Attribute values correctly.

The second part of the output (Listing 2) shows the results of the health status inquiry. This is the one-line Executive Summary Report of disk health; the disk shown here has passed. If your disk health status is FAILING, back up your data immediately. The remainder of this section of the output provides information about the disk's capabilities and the estimated time to perform short and long disk self-tests.

The third part of the output (Listing 3) lists the disk's table of up to 30 Attributes (from a maximum set of 255). Remember that Attributes are no longer part of the ATA standard, but most manufacturers still support them. Although SFF-8035i doesn't define the meaning or interpretation of Attributes, many have a de facto standard interpretation. For example, this disk's 13th Attribute (ID #194) tracks its internal temperature.

Studies have shown that lowering disk temperatures by as little as 5^C significantly reduces failure rates, though this is less of an issue for the latest generation of fluid-drive bearing drives. One of the simplest and least expensive steps you can take to ensure disk reliability is to add a cooling fan that blows cooling air directly onto or past the system's disks.

Each Attribute has a six-byte raw value (RAW_VALUE) and a one-byte normalized value (VALUE). In this case, the raw value stores three temperatures: the disk's temperature in Celsius (29), plus its lifetime minimum (23) and maximum (33) values. The format of the raw data is vendor-specific and not specified by any standard. To track disk reliability, the disk's firmware converts the raw value to a normalized value ranging from 1 to 253. If this normalized value is less than or equal to the threshold (THRESH), the Attribute is said to have failed, as indicated in the WHEN_FAILED column. The column is empty because none of these Attributes has failed. The lowest (WORST) normalized value also is shown; it is the smallest value attained since SMART was enabled on the disk. The TYPE of the Attribute indicates if Attribute failure means the device has reached the end of its design life (Old_age) or it's an impending disk failure (Pre-fail). For example, disk spin-up time (ID #3) is a prefailure Attribute. If this (or any other prefail Attribute) fails, disk failure is predicted in less than 24 hours.

The names/meanings of Attributes and the interpretation of their raw values is not specified by any standard. Different manufacturers sometimes use the same Attribute ID for different purposes. For this reason, the interpretation of specific Attributes can be modified using the -v option to smartctl; please see the man page for details. For example, some disks use Attribute 9 to store the power-on time of the disk in minutes; the -v 9,minutes option to smartctl correctly modifies the Attribute's interpretation. If your disk model is in the smartmontools database, these -v options are set automatically.

The next part of the smartctl -a output (Listing 4) is a log of the disk errors. This particular disk has been error-free, and the log is empty. Typically, one should worry only if disk errors start to appear in large numbers. An occasional transient error that does not recur usually is benign. The smartmontools Web page has a number of examples of smartctl -a output showing some illustrative error log entries. They are timestamped with the disk's power-on lifetime in hours when the error occurred, and the individual ATA commands leading up to the error are timestamped with the time in milliseconds after the disk was powered on. This shows whether the errors are recent or old.

The final part of the smartctl output (Listing 5) is a report of the self-tests run on the disk. These show two types of self-tests, short and long. (ATA-6/7 disks also may have conveyance and selective self-tests.) These can be run with the commands smartctl -t short /dev/hda and smartctl -t long /dev/hda and do not corrupt data on the disk. Typically, short tests take only a minute or two to complete, and long tests take about an hour. These self-tests do not interfere with the normal functioning of the disk, so the commands may be used for mounted disks on a running system. On our computing cluster nodes, a long self-test is run with a cron job early every Sunday morning. The entries in Listing 5 all are self-tests that completed without errors; the LifeTime column shows the power-on age of the disk when the self-test was run. If a self-test finds an error, the Logical Block Address (LBA) shows where the error occurred on the disk. The Remaining column shows the percentage of the self-test remaining when the error was found. If you suspect that something is wrong with a disk, I strongly recommend running a long self-test to look for problems.

The smartctl -t offline command can be used to carry out off-line tests. These off-line tests do not make entries in the self-test log. They date back to the SFF-8035i standard, and update values of the Attributes that are not updated automatically under normal disk operation (see the UPDATED column in Listing 3). Some disks support automatic off-line testing, enabled by smartctl -o on, which automatically runs an off-line test every few hours.

The smartd daemon does regular monitoring for you. It monitors the disk's SMART data for signs of problems. It can be configured to send e-mail to users or system administrators or to run arbitrary scripts if problems are detected. By default, when smartd is started, it registers the system's disks. It then checks their status every 30 minutes for failing Attributes, failing health status or increased numbers of ATA errors or failed self-tests and logs this information with SYSLOG in /var/log/messages by default.

You can control and fine-tune the behavior of smartd using the configuration file /etc/smartd.conf. This file is read when smartd starts up, before it forks into the background. Each line contains Directives pertaining to a different disk. The configuration file on our computing cluster nodes look like this:

The first column indicates the device to be monitored. The -o on Directive enables the automatic off-line testing, and the -S on Directive enables automatic Attribute autosave. The -m Directive is followed by an e-mail address to which warning messages are sent, and the -a Directive instructs smartd to monitor all SMART features of the disk. In this configuration, smartd logs changes in all normalized attribute values. The -I 194 Directive means ignore changes in Attribute #194, because disk temperatures change often, and it's annoying to have such changes logged on a regular basis.

Normally smartd is started by the normal UNIX init mechanism. For example, on Red Hat distributions, /etc/rc.d/init.d/smartd start and /etc/rc.d/init.d/smartd stop can be used to start and stop the daemon.

Further information about the smartd and its config file can be found in the man page (man smartd), and summaries can be found with the commands smartd -D and smartd -h. For example, the -M test Directive sends a test e-mail warning message to confirm that warning e-mail messages are delivered correctly. Other Directives provide additional flexibility, such as monitoring changes in raw Attribute values.

What should you do if a disk shows signs of problems? What if a disk self-test fails or the disk's SMART health status fails? Start by getting your data off the disk and on to another system as soon as possible. Second, run some extended disk self-tests and see if the problem is repeatable at the same LBA. If so, something probably is wrong with the disk. If the disk has failing SMART health status and is under warranty, the vendor usually will replace it. If the disk is failing its self-tests, many manufacturers provide specialized disk health programs, for example, Maxtor's PowerMax or IBM's Drive Fitness Test. Sometimes these programs actually can repair a disk by remapping bad sectors. Often, they report a special error code that can be used to get a replacement disk.

documented on: 2008-03-29

You do a low-level format on a floppy disk with "fdformat" or "superformat". Modern hard disks *can* have their sector headers, interleave factors, cylinder skew, and all that adjusted, but you have to get special software from the drive manufacturer, and the software generally is specific to a particular model of drive. This stuff must be put on floppy for obvious reasons, and either has its own miniature homebrew OS or uses DOS.

If you have a hard disk that's spitting out unrecoverable errors that have to do with bad blocks, you can buy some time by moving all the data you want to save somewhere else, running "badblocks" on the partition, then running "badblocks -o /tmp/somewhere" on the partition, then doing "mke2fs -l /tmp/somewhere" on the partition. This is a *temporary* solution; when a disk starts dying, it just gets worse and worse.

Matt G

Modern drives remap bad blocks all by themselves. If you (or the O/S) see bad blocks, then it's time to replace the drive. And if the drive is old enough that it doesn't remap bad blocks, it should be replaced.

But if you want to run diagnostics, check the vendor's web site. They probably have tools that you can download and run from a DOS floppy.

Howard Christeller

This is not fully done on new systems because the IDE interface does not use this information anymore.

The modern drives of the IDE/ATA variety actually use the LBA absolute sector number for everything, No matter how you address the drive.

To do the format like you are talking about you must first tell the drive to use your CHS cylinder, head, sector values.

Then you just go ahead and find the appropriate commands in the list IDE/ATA low level stuff and send it.

These are generically known as P&G tables. Permanent and gathered errors table or list.

This idea comes from SCSI which is where much of the modern improvments in IDE have come from. Approximatly 3% of the drive on a physical track by physical track basis is set aside to catch gathered errors as they occur.

In order to fully under stand this look at a modern drive size.

162000 * 16 * 63 done on an actual 2 platter or 4 Head system. (~80-Gig)

this means that you actually deal with the following.

648000 * 4 *63 is the first step.

Then you factor in the 6000Tpi of tracks per inch density. the track are the same as cylinders (concentric rings goinf outward.) You actually have about an inch of track width on a 3 1/2 drv. so you actually get something like.

6000 * 4 * 6804 is where you end up.

Now if it was me I would just use the 6144 (1024 * 6) as my SPT (Sectors per track) or about 3Megs per physical track on the media.

This illustrate the departure of the IDE/ATA technology from it's FM / MFM / RLL / ESDI roots. The sector address no longer represented the physical address of the sector. This now represented a virtual position and could be changed at will by the onboard electronics for data preservation. All commands to access the P&G tables are vendor specific.

Please see the above then add this to it.

Modern drives use a two layer approach to a format. The sector boundary's are no longer variable.

Now there is an inner layer of hard coded sectors that the onboard electronics can only read nor write. Then there is the soft coded parts that contain sector specific data. This can be CHS placement Information in addition to LBA address & sector data.

If you really want to get into the nitty gritty then I suggest you grab the BT168.zip off of my site and study it closely.

Messy though the code is, poorly documented it may be. How ever it runs spinrite. It also handles upto 128 Gig drives. in CHS upto 8-Gig and in LBA from there up.

Done myself from the ground up. When I get time I will be cleaning up the code and makeing some real documemtation for it.

Doors - Dont look at the future in a window. just walk to the door http://walk.to/doors - Open it and go there.

There are 3 files in this mail:

http://www.tuttogratis.it/software_gratis/benchmark_hard_disk.html http://translate.google.com/translate?hl=en&sl=it&u=http://www.tuttogratis.it/software_gratis/benchmark_hard_disk.html

Version for Linux di Hitachi Drive Fitness Test v 3.40. Freeware (1,4 Mb)

http://www.benchmarkhq.ru/english.html?/be_hdd.html

Active SMART is a the hard disk drive monitoring and failure prediction software. It uses S.M.A.R.T. technology to monitor the health status of hard disk drives, prevents data loss and predicts possible drive fail. If a fault is detected, you are notified with various local alerting options or you can enable remote notifications via e-mail or other network mail applications with the drive ID and the time of the first fault. Active SMART monitors all important HDD parameters. You can track every S.M.A.R.T. parameter of your HDD, and get the information about every drive's attribute: attribute's value, it's threshold level and worst value for the attribute. Also it shows the information about HDD: serial number, drive logical information, current mode and other.

You can also download Active SMART SCSI edition with SCSI drives support. Active SMART SCSI edition supports hard drives on SCSI controllers and SCSI RAID arrays. Active SMART SCSI edition supports up to 4 IDE/ATA and up to 8 SCSI drives.

CHDDSPEED is a console utility, which tests the performance of various block devices (HDD, CD, Flash, etc.). This version (0.1) includes two tests: multisector read test and random read test.

Disk Bench tests your hard drive speed in a real life situation not in a benchmarking environment. All it does is copies a file from A to B, times the time it took, and deletes the file from B again. Theoretically, it can test not only hard drives. You will need to have .net framework installed. You can get this from windowsupdate or from MSDN Downloads.

This program tests the speed of drives attached to your computer. Disk Speed reports the linear read transfer rate, the random read transfer rate and also the access time of the drive.

DiskSpeed32 is a hard drive speed analyzer. DiskSpeed32 reads sequently sectors of hard drive and plots a dependence of reading speed by cylinder number. Allows to test formatted and not formatted hard drives as well. Allows to check hard drives performance and to find mapped tracks on hard drives.

This program will measure the performance of your hard drives, running under Windows NT.

This program measures both sustained and burst data transfer rates of your hard disks, cd/dvd-roms and floppy. It features a realtime graphical display.

HD Tach is a physical performance hard drive test for Windows 95/98 and Windows NT. In Windows 95/98 it uses a special kernel mode VXD to get maximum accuracy by bypassing the file system. HD Tach tests the drive's random access time, sequential read, CPU utilization ect.

IDEdrive interrogates your IDE-drives and displays detailed information about them (geometry, features, transfer modes, etc.).

Iometer is an I/O subsystem measurement and characterization tool for single and clustered systems. It was developed by the Intel Corporation. Meanwhile Intel has discontinued to work on Iometer and it was given to the Open Source Development Lab (OSDL). Iometer is also available for Linux and Solaris. http://sourceforge.net/project/showfiles.php?group_id=40179&release_id=159909

IOzone is a filesystem benchmark tool. The benchmark generates and measures a variety of file operations. Iozone has been ported to many machines and runs under many operating systems. The benchmark tests file I/O performance for the following operations: read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read, pread, mmap, aio_read, aio_write.

Quick Bench is a small utility to check that your disks are configured properly by benching them and getting the average sequential read speed as well as the CPU load. This lets you know that the DMA (Direct Memory Access) is working properly for the disk.

SCSITOOL is a diagnostics and benchmarking tool for SCSI (storage) devices. Currently supported device types are: harddisk, tape, cd-rom, optical and removable. It has a load of tests, can low level format any number of drives simultaneously, can copy one source drive to more than one target drives, and more.

This little program will read the S.M.A.R.T. information of your hard drive(s). It supports external UDMA-controllers and will predict possible drive fail.

Adaptec?s ThreadMark benchmark measures multithreaded I/O performance on computers running Microsoft Windows NT or Windows 95/98. You can use ThreadMark to compare the performance of different disk drives and host adapters, in order to find the optimal I/O solution for your Windows desktop environment. Because ThreadMark uses the same Win32 API calls that other applications use, it makes unbiased performance measurements on any SCSI or EIDE disk drive or host adapter.

xHDDSpeed tests the performance of a hard drive. It performs such tests as average seek time, access time, linear speed, etc. The program also gives some information about the drive.

http://www.linuxplanet.com/linuxplanet/reports/3029/

http://linuxtoday.com/infrastructure/2001022200520PSHW

Modern desktop computers are so fast in all respects that we often have the luxury of ignoring performance issues. (People like me who started with a 1MHz processor have no trouble remembering how we lusted after every extra slice of CPU speed.) But if you're in a position where you need or want to maximize your computer's speed, all but the most compute-bound tasks will likely benefit from a faster disk drive system. Which raises the question: Aside from reading specs (which are really just a first cousin to statistics in terms of veracity), how do you evaluate the performance of a disk drive?

My favorite tool in this area is iozone, a relatively small but full-featured open source program for benchmarking disk systems. iozone was written by William Norcott and Don Capps, with contributions credited in the source code from several other people, and it can be built for over two dozen OS's and versions, including Linux, Windows (32-bit), several BSD's, and Solaris.

http://www.linuxplanet.com/linuxplanet/reports/3029/2/

http://www.linuxgazette.com/issue23/bench2.html

by Andr? D. Balsa v0.4, 26 November 1997

This is the second article in a series of 4 articles on GNU/Linux Benchmarking, to be published by the Linux Gazette. The first article presented some basic benchmarking concepts and analyzed the Whetstone benchmark in more detail. The present article deals with practical issues in GNU/Linux benchmarking: what benchmarks already exist, where to find them, what they effectively measure and how to run them. And if you are not happy with the available benchmarks, some guidelines to write your own. Also, an application benchmark (Linux kernel 2.0.0 compilation) is analyzed in detail.

GNU/Linux is a great OS in terms of performance, and we can hope it will only get better over time. But that is a very vague statement: we need figures to prove it. What information can benchmarks effectively provide us with? What aspects of microcomputer performance can we measure under GNU/Linux?

Kurt Fitzner reminded me of an old saying: "When performance is measured, performance increases."

Let's list some general benchmarking rules (not necessarily in order of decreasing priority) that should be followed to obtain accurate and meaningful benchmarking data, resulting in real GNU/Linux performance gains:

These are some benchmarks I have collected over the Net. A few are Linux-specific, others are portable across a wide range of Unix-compatible systems, and some are even more generic.

All the benchmarks listed above are available by ftp or http from the Linux Benchmarking Project server in the download directory: www.tux.org/pub/bench or from the Links page.

We have seen last month that (nearly) all benchmarks are based on either of two simple algorithms, or combinations/variations of these:

We also saw that the Whetstone benchmark would use a combination of these two procedures to "calibrate" itself for optimum resolution, effectively providing a workaround for the low resolution timer available on PC type machines.

Note that some newer benchmarks use new, exotic algorithms to estimate system performance, e.g. the Hint benchmark. I'll get back to Hint in a future article.

Right now, let's see what algorithm 2 would look like:

Here, time() is a system library call which returns, for example, the elapsed wall-clock time since the last system boot. Benchmark_kernel() is obviously exercising the system feature or characteristic we are trying to measure.

Even this trivial benchmarking algorithm makes some basic assumptions about the system being tested and will report totally erroneous results if some precautions are not taken:

You can substitute the benchmark "kernel" with whatever computing task interests you more or comes closer to your specific benchmarking needs.

Examples of such kernels would be:

For good examples of actual C source code, see the UnixBench and Whetstone benchmark sources.

The more one gets to use and know GNU/Linux, and the more often one compiles the Linux kernel. Very quickly it becomes a habit: as soon as a new kernel version comes out, we download the tar.gz source file and recompile it a few times, fine-tuning the new features.

This is the main reason for proposing kernel compilation as an application benchmark: it is a very common task for all GNU/Linux users. Note that the application that is being directly tested is not the Linux kernel itself, it's gcc. I guess most GNU/Linux users use gcc everyday.

The Linux kernel is being used here as a (large) standard data set. Since this is a large program (gcc) with a wide variety of instructions, processing a large data set (the Linux kernel) with a wide variety of data structures, we assume it will exercise a good subset of OS functions like file I/O, swapping, etc and a good subset of the hardware too: CPU, memory, caches, hard disk, hard disk controller/driver combination, PCI or ISA I/O bus. Obviously this is not a test for X server performance, even if you launch the compilation from an xterm window! And the FPU is not exercised either (but we already tested our FPU with Whetstone, didn't we?). Now, I have noticed that test results are almost independent of hard disk performance, at least on the various systems I had available. The real bottleneck for this test is CPU/cache performance.

Why specify the Linux kernel version 2.0.0 as our standard data set? Because it is widely available, as most GNU/Linux users have an old CD-ROM distribution with the Linux kernel 2.0.0 source, and also because it in quite near in terms of size and structure to present-day kernels. So it's not exactly an out-of-anybody's-hat data set: it's a typical real-world data set.

Why not let users compile any Linux 2.x kernel and report results? Because then we wouldn't be able to compare results anymore. Aha you say, but what about the different gcc and libc versions in the various systems being tested? Answer: they are part of your GNU/Linux system and so also get their performance measured by this benchmark, and this is exactly the behaviour we want from an application benchmark. Of course, gcc and libc versions must be reported, just like CPU type, hard disk, total RAM, etc (see the Linux Benchmarking Toolkit Report Form).

Basically what goes on during a gcc kernel compilation (make zImage) is that:

Step 2 is where most of the time is spent.

This test is quite stable between different runs. It is also relatively insensitive to small loads (e.g. it can be run in an xterm window) and completes in less than 15 minutes on most recent machines.

Do I really have to tell you where to get the kernel 2.0.0 source? OK, then: ftp://sunsite.unc.edu/pub/Linux/kernel/source/2.0.x or any of its mirrors, or any recent GNU/Linux CD-ROM set with a copy of sunsite.unc.edu. Download the 2.0.0 kernel, gunzip and untar under a test directory (tar zxvf linux-2.0.tar.gz will do the trick).

Cd to the linux directory you just created and type make config. Press <Enter> to answer all questions with their default value. Now type make dep ; make clean ; sync ; time make zImage. Depending on your machine, you can go and have lunch or just an expresso. You can't (yet) blink and be done with it, even on a 600 MHz Alpha. By the way, if you are going to run this test on an Alpha, you will have to cross-compile the kernel targetting the i386 architecture so that your results are comparable to the more ubiquitous x86 machines.

This is what I get on my test GNU/Linux box:

186.90user 19.30system 3:40.75elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k

0inputs+0outputs (147838major+170260minor)pagefaults 0swaps

The most important figure here is the total elapsed time: 3 min 41 s (there is no need to report fractions of seconds).

If you were to complain that the above benchmark is useless without a description of the machine being tested, you'd be 100% correct! So, here is the LBT Report Form for this machine:

LINUX BENCHMARKING TOOLKIT REPORT FORM

CPU

What size datasets are you using? Bonnie++ is still a good benchmark, although it stresses things differently. The maximum number of threads that you should need to (or probably even want to) run is between 2x and 3x the number of disks that you have installed. That should ensure that every drive is pulling 1 piece of data, and that there is another thread that is waiting for data while that one is being retrieved.

Gregory Leblanc

http://wauug.erols.com/~balsa/linux/benchmarking/HOWTO/Benchmarking-HOWTO-0.15-3.html http://www.linux.org/docs/ldp/howto/Benchmarking-HOWTO-3.html

This is a proposal for a basic benchmarking toolkit for Linux, to be expanded and improved. Take it for what it's worth, i.e. as work-in-progress.

I wrote a benchmark in order testing Linux disk speed are compare result with other OS especialy NT and QNX.

You can retreive source at:

ftp://ftp.fridu.com/pub/fridu/bench.tgz

General aim

I currentely tested

pPro with IDE: pProc with Adpated Ultra Wide bi pProc with DPT raid0 (2disk array and 32MB cache)

The benchmark provide 3 tests:

Avaliable options are:

First result

HOW to

Final result

Warning

http://www.pragmanet.it/hppersonali/user827/POSBB.htm

POSBB is a new benchmark program,with which you will be able to test and compare different computers,Operating Systems,CPUs,and even C compilers. It will be able to perform many tests,and the user will select wich test want to use. Later also graphical frontends for many platforms will arrive.

POSBB means Portable OS-Based Benchmark.

Portable because there will be portings for many platforms and I'll send the sources to everyone who wants to help me.

OS-Based because it will use functions of the Operating Systems,or ANSI C functions,but NEVER custom routines. I'll do so because I want to test the performances that real programs would have on a given computer and Operating System,not the raw power of the hardware.

Benchmark doesn't need any other word.

At this time there's two version of Posbb: Amiga and "generic". The first do all the tests I've finished, the seconds lack graphical ones and it will enver have them. In fact the "generic" version is compatible with every computer on Earth which has a C compiler. You can compile it on every platforms without changing anything.

Click here http://www.pragmanet.it/hppersonali/user827/myprgs/posbb.lha to download via HTTP the latest archive available. (Amiga v0.23,generic v0.12) (about 146 kb) It will be available on the Aminet soon ( check util/moni/Posbb.lha ). In the archive you will find the Amiga (m68k and PPC,optimized for all 680x0s),Linux (i386) and MS Windows (32bit) executables,sources,docs,results of tests on some machines.

Last Update 02 May 98

documented on: 2007.01.12