🚀 go-pugleaf

John Kheit (jkheit@cnj.digex.net) wrote:
: 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.

: 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.

: 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).

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

the benchmarks ARE a joke.  All they are for is the marketing dept.  Its 
kinda like the engine dynos in the car industry.  You go buy a race motor 
from some guy and he gives you this outrageous HP number.  well the dyno 
*did* see that number, but it was obtained by reving the motor up with no 
load and then turning on the dyno, like bringing your motor up to 7000RPM 
and then throwing it into gear.  Yes, you get the big HP numbers, but its 
a peak, not a norm. not to mention your motor just lost quite a few races 
off its life with  that kind of abuse.

so basically the bechmakrks (and dynos) are a good tool that are abused 
for a buck.
 --

Dave
                :=--=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-:
                :::  In  Irons BBS  :::::::::::::::   
       /|       :::"Your Home/2":::::::::::::::
      / |       :::(516) 427-3775::::::::::
     /  |       :::Home of HUNware::::::
    /   |       :::dave-a@li.net::::
   /____|       :=-=-=-=-==-=-=-=-
   _____|_____  
   \         /  
  ~~~~~~~~~~~~~  

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

                                            

On 02/21/96, John Kheit wrote:

>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.

>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.

Whoa!  I agree that many benchmarks are way too easily fooled by cache and that 
IOZone is one of the better benchmarks when used with a large enough test file.  
(I also like IOStone too.)

However: 

a) Barracuda 2 and Barracuda 4 series CAN actually achieve close to 7 MB/second 
doing continuous reads/writes from certain zones.  Hook 'em up to an appropriate 
controller on an Amiga (which has really tiny OS/FS overhead) and you can almost 
achieve transfers at that rate even going through the filesystem in real world 
situations.  Of course, real world also involves some seeking but....  (And then 
there are the 12450W and the new 4LP and 8 Barracuda series which look like they 
can achieve close to 14 MB/second internal transfer rate from the media.)

b) NEXTSTEP sucks in terms of driver/file-system performance and in this case is 
negatively impacting the figures that are being reported rather than reporting 
them "accurately."   Case in point:  IOZone exists for many Unix variants.  Take 
an Intel box.  Install NeXTSTEP/fip.  Run IOZone.  Remove NeXTSTEP and install 
Linux, FreeBSD, NetBSD or another Unix (Solaris maybe?) on the same system.  Run 
IOZone and watch your numbers double.  I haven't quite ever been able to figure 
out if this is a filesystem or driver-system problem on NeXTSTEP (and no it 
doesn't seem to be a problem with any one particular driver.)

-- 
Christopher Wolf - WolfWare - cwolf@wolfware.com (NeXTmail & MIME accepted)
---------------------------------------------------------------------------
       NewsFlash Version 2 - a threaded NeXTSTEP Usenet newsreader -
       is now available.  Visit http://www.wolfware.com for details!

John,
If your program is shareware or freeware, where can I get a copy? What 
are distribution policies?
-- 
Regards,
Tom
tbewley@localnet.com

>I have a scsi-3 controller (fast-wide ncr825 based pci from tyan) and the 
>following company sells both scsi-3 controllers and disks (conner):
>Corporate Systems Center
>1294 Hammerwood Ave.
>Sunnyvale, CA 94089
>408-734-3475
>
>The controllers run in os/2 and suport scsi2 and scsi3 disks.  I have not 

The disks that I've seen listed are FW-SCSI-II/III units which have a 20mb/sec
transfer rate, they are NOT the ULTRA-wide disks @ 40mb/sec transfer rate
that I'm hoping to see in the near future :)   [Still, I'm sorely tempted to get
one!]

>benchmarked them for speed yet, but they seem at least as fast as my 
>pio-4 and pio-3 eide disks.  The disks are available in 1050 and 2.1 gb 
>sizes.  The 1 gig drive is $259.  They have a web page, but I can't 
>recall the url, sorry.

The URL is:   http://WWW.CORPSYS.COM

In <4gma3b$l9r@shellx.best.com>, cwolf@wolfware.com said:

>
>On 02/21/96, John Kheit wrote:

>>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.

>>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.

>Whoa!  I agree that many benchmarks are way too easily fooled by cache and
>that IOZone is one of the better benchmarks when used with a large enough
>test file.  (I also like IOStone too.)

>However: 

>a) Barracuda 2 and Barracuda 4 series CAN actually achieve close to 7
>MB/second doing continuous reads/writes from certain zones.  Hook 'em up
>to an appropriate controller on an Amiga (which has really tiny OS/FS
>overhead) and you can almost achieve transfers at that rate even going
>through the filesystem in real world situations.  Of course, real world
>also involves some seeking but....  (And then there are the 12450W and
>the new 4LP and 8 Barracuda series which look like they can achieve close
>to 14 MB/second internal transfer rate from the media.)

That is why I feel that an accurate benchmarking program will go through the
OS and perform real reads and writes on real files.  That is what prompted
me to write the program I used. :-)


>b) NEXTSTEP sucks in terms of driver/file-system performance and in this
>case is negatively impacting the figures that are being reported rather
>than reporting them "accurately."   Case in point:  IOZone exists for
>many Unix variants.  Take an Intel box.  Install NeXTSTEP/fip.  Run
>IOZone.  Remove NeXTSTEP and install Linux, FreeBSD, NetBSD or another
>Unix (Solaris maybe?) on the same system.  Run IOZone and watch your
>numbers double.  I haven't quite ever been able to figure out if this is
>a filesystem or driver-system problem on NeXTSTEP (and no it doesn't seem
>to be a problem with any one particular driver.)

It must.  2MB/sec with a Barracuda is TERRIBLE!!!  The drive I tested on was
just a Hawk...

Thanks for providing some support, I am tiring of the flames.


--
jcorigan@teleport.com (John Corrigan)



.. How do you make Windows faster?  Throw it harder!
-- MR/2 2.26 #314

                             

In <312FC7BF.2ED8@localnet.com>, tbewley@localnet.com said:

>
>John,
>If your program is shareware or freeware, where can I get a copy? What
>are distribution policies?
>

It is shareware, however it is still in somewhat early beta -- I decided
that I wanted to add more to it before distributing it.  However, I sent you
a copy via e-mail.  If anyone else would like one to play with, please feel
free to e-mail me.  However, I do NOT want this widely distributed yet as it
is still a work in progress.  I need to finish up a library that I have been
working on and then rewrite the benchmark to use the new library (DOS,
DOS4GW, and OS/2 text based windowing library).  This also requires porting
the code from Borland C++ to Watcom C++.  After that is done I will be
adding a database of some sort to show performance comparisons.  

--
jcorigan@teleport.com (John Corrigan)



.. Have you crashed your Windows today?
-- MR/2 2.26 #314