🚀 go-pugleaf

In <4ggore$b0s@news4.digex.net>, jkheit@cnj.digex.net said:

>
>jcorigan@teleport.com (John Corrigan) wrote:
>> I recently benched a 2940 with a Seagate Hawk (2GB, 5400RPM,
>> SCSI2-F) and it showed transfer rates of 6.7MB/sec for both reads
>> and writes for file sizes up to 4MB.  (The benchmark creates the
>> file and times the write speed and the read speed, the tests were
>> done with no software disk caching).  Sounds to me like there
>> isn't much of a benefit to going to SCSI2-UW :)

>Under most DOS benchmarks I get rediculous read/write performance reports. 
>My barracuda also gets around 6.7m/sec (and its not wide or anything)... 
>Under NeXTSTEP (i.e. Unix variant) and using IOzone (an excellent
>benchmark, don't know if it exists for other OS's) I get more accurate
>reports around 2m/sec.

Well, I happened to have written the above "bogus" benchmark program.  The
program works by writing a file a set number of times and then reading it a
set number of times.  Each file is timed from the first read/write until the
last read/write.  The timer does not start until after the file has been
opened and it is stopped before the file is closed.  I have compiled both
DOS and OS/2 versions of it.  The above results were obtained under MS-DOS
6.0 with a clean config.sys and autoexec.bat -- THE ONLY DISK CACHE EMPLOYED
WAS 512KB CACHE ON THE DRIVE ITSELF.

If you are only getting 2MB/sec with a Barracuda and a BUSMASTERING
controller, I would say that the benchmark program isn't getting adequate
time from the OS, there is a configuration problem, or there is a flaw in
the methodology of the benchmark.  When measuring throughput of a disk
drive, it is important that other applications are not tieing up the CPU or
the SCSI bus to get an accurate result.  Running a benchmark in a window, or
in the background, instead of foreground full screen session, will
significantly degrade the reported performance.


>IOzone simulates real world read/writes, and is careful to make the test
>file big enough so there are no secondary memory caching effects.  I.E. if
>you have 32megs of RAM and you use a test file of only 8megs, odds are
>that significant portions of it will be cached by the system.

Simulates real world...  I thought that was what my program was doing. 
Testing a 4MB file on a system with NO SOFTWARE DISK CACHE and only a 512KB
cache on the drive should be a large enough test to counter caching affects.
I considered going with an even larger file size, but on IDE systems the
program already takes forever to run and in the real world there is not much
call for reading or writing more than 4MB of data at a time. :)  I would
also like to point out that software caching does not always help
performance.  On files larger than the cache it often hurts it -- especially
NCACHE.  Basically, most caching software (for DOS) either helps reads or
writes, but not both.


>Most DOS apps are worse yet, in that they send single blocks (yes
>sequential, but they still get cached by the system) of X size (maybe 64k,
>which is nothing).

I will agree that just about all disk benchmarking programs are a crock. 
That is why I wrote my own.  I figure that my program is pretty close to
real world usage for sequential I/O of large chunks of data (EX: loading an
EXE file).  Open a file, start a timer, read or write the file, stop the
timer, close the file...  Just like a real application would do with the
exception of two calls to get the time.  The benchmark does use buffered I/O
(16KB blocks), but most real world apps that do much I/O do that as well.

>That's why you see such great disparity between the 'make me feel good
>benchmarks' and the real world file copy times.

Sorry, but my benchmark was real world, not "make me feel good."  The
benchmark does a great job of showing how transfer rates deteriorate with
fragmentation and as the data is written closer to the center of the disk. 
Again, I wrote the benchmark because I wanted some REAL numbers and was
tired of jokes like SYSINFO (either Norton or PCTools) that gave different
results depending on which version you ran.  Just for kicks, I did run
Norton SI 8.0 on the same system and it showed that the WDAC340 was FASTER
than the Hawk.  Definately a bad JOKE! :)

As to timing file copies, that is not necessarily an accurate measure of
throughput.  The program used to copy the files may not be written with
performance in mind.  The program used to copy the files may also verify
after writing.  If copying from the same physical drive as the file is being
copied to, there is a lot more head movement going on -- especially if the
file is being copied to a different partition.

--
jcorigan@teleport.com (John Corrigan)
Advanced Operating Systems  1.503.370.4207  FIDO 1:3406/25  USR DS v.34+



.. "If you can't make it good, make it LOOK good." - B Gates
-- MR/2 2.26 #314