HDTEST and RNDHDTST client/network/server/HD benchmark test.

http://www.otcnetworks.com/HDTEST.ZIP

HDTEST.EXE is a DOS application designed to test for proper disk drive operation, particularly IDE issues such as incompatible sector translation between the Disk, BIOS, and/or operating system drivers. It operates by writing files with unique identifiers in each sector (512 bytes), then reading the files and verifying the result.

Type HDTEST /H for basic help.

Below are some undocumented features and methods of using it to test local and network drives.

Switches and command line parameters (order of parameters is irrelevant and they are NOT case sensitive):

HDTEST [ddd] [/Y] [Q] [/M########] [/H]

ddd = one or more drive letters.

/H = display help screens

/Q = enable quick test mode. Reads all sectors, but only verifies contents of some sectors. May provide a slightly faster benchmark result on slower machines.

/Y = bypass "Do you want to proceed" prompt

/MAX = use maximum file size (~2GB) allowing testing a volume up to 510GB. Same as /M4193920

/M## = maximum sectors (512 bytes) per test file. Since HDTEST uses a maximum of 255 test files per directory, increasing this value makes testing of larger volumes possible. Valid values are 640 to 4,193,920. Program will round the result down to the nearest multiple of 640. Values outside this range will be ignored. The default value of 384,000 results in a 192MB test file, which allows testing volumes up to 50GB (192MB*255 files). Do NOT include comma's in number. Maximum value produces a file of 2GB, which allows testing a single volume up to 510GB.

Example: HDTEST def /y

will run HDTEST on the D:, E:, and F: volumes

When HDTEST completes, it DOES NOT delete the test files it creates because you may wish to test multiple times

Example:

HDTEST DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD /y

will repeatedly test drive D: This is useful as a burn in test, or when you think you might have a flaky or failing drive.

or you may need to reboot in a different OS to access other volumes/partitions, then return and retest the original partitions. Therefore, it's left to the user to delete all TEMPFILE.$* files created by HDTEST.

New files are created if TEMPFILE.$00 is not found in the current directory of the drive being tested. HDTEST continues writing until an error occurs (such as disk full), or the user presses Escape.

Benchmarking notes:

Disable or minimize local OS caching for the most accurate results. This applies to local and network drives. When caching can't be eliminated, make sure your test files are at least twice the size of the total cache memory (including any on a RAID controller, local OS, or Server). HDTEST reports it's progress in sectors, there are about 2000 sectors per MB. OS specific suggestions are below.

Special note for Windows NT/2k/XP users:

Update: HDTEST v1.02 and later now provide more accurate results under NT4/2k/XP. Results can still be skewed by caching, but the clock synchronization issue is mostly fixed, it now only occurs on machines with particularly slow disk systems.

HDTEST reports Minimum, Maximum, and Average transfer rate in KBytes per second when performing Write and Read operations. As noted in the help, performance numbers reported under Windows NT/2k/XP writing to local drives or network drives where local caching is allowed are not accurate because the DOS VDM doesn't synchronize the emulated clock with the real-time clock and the emulated clock runs significantly slower when the OS is paging or trying to flush a nearly full cache. You can time it with a stop watch if you need accurate benchmarks under those OS's. Read timing (except the automatic verify after a write operation) under those OS's is reasonably accurate.

DOS users: Disable SMARTDRV when benchmarking local drives. Set BUFFERS = 30 or more in CONFIG.SYS. Test with a 1024+ MB (1+GB) volume for maximum performance. When testing to a NetWare server, use the VLM client v1.21 and leave packet burst enabled (it's enabled by default)

Win9x/ME/NT/2k/XP users: I don't know how to disable caching for local drives or for connections to Windows (NT/W2k) servers, so make sure to use a large test. Before testing to a NetWare server, set the following settings on the Novell Client to disable local caching.

Win95/98/ME clients:

Cache Writes = off

Delay Writes = off

File Write Through = on

Opportunistic Locking = off

All other settings at the default values

WinNT/2k/XP clients:

Burst Mode = on (I’ve read that W2k machines may be faster with this setting off, but I have not seen that)

File Caching = off

File Commit = off

All other settings at the default values

Other uses:

Benchmarking network drives and servers. Map a network drive to a local drive letter and run HDTEST against it to see what your sustained network throughput is. Run concurrently on multiple workstations (each mapped to a different volume or directory) to stress the server (disk system, NIC, cache, etc). Add up aggregate throughput from all machines.

Benchmarking RAID hardware and software. With some RAID controllers I've tested, mirroring (RAID 1) or Striping (RAID 0) are significantly slower than a single drive, which is not supposed to be the case with these RAID levels.

One interesting use when testing RAID 1 (mirroring) configurations is to run HDTEST first in one directory, then in a second directory noting the performance of each. Then run two copies (one in each directory) concurrently to see if the RAID HW/SW performs split seeks. If split seeks are supported, performance with both instances reading will each be nearly the same as each run individually yielding nearly twice the throughput of one instance alone. If split seeks are not supported, performance per instance will be significantly lower than a single instance (typically 1/3 to 1/5 the speed of a single instance). Another indication that split seeks are supported is that both drives in a mirror will be active when concurrently reading in two separate instances of HDTEST. Split seeks are very important in true multi-user access situations and in multi-threaded databases such as Btrieve, Oracle and other SQL servers.

When testing over a 10Mb network connection, performance will top out at about 1050K/s, on a 100Mb network, you might see figures up to 9100K/s with 80-90% of those numbers being typical of a well configured NetWare or NT server.

I've also used this to benchmark the Samba server for Linux from Windows workstations.

I've used it over WAN links to servers as well. In these cases, it's VERY important to disable local caching as it can quickly fill a multi MB cache that might take minutes to write out over a WAN. Also of note is that the data HDTEST writes is very compressible so WAN connections that offer compression may appear to provide 2-4 times the performance that their bit rate can sustain on more typical data.