Xref: utzoo comp.unix.i386:694 comp.unix.xenix:7946
Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!uwm.edu!mailrus!ncar!asuvax!mcdphx!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.i386,comp.unix.xenix
Subject: Re: Mylex SCSI Controller, 16550A UARTS
Summary: Information on throughput
Message-ID: <1989Oct6.194539.16416@ddsw1.MCS.COM>
Date: 6 Oct 89 19:45:39 GMT
References: <111016@nstar.UUCP> <707@fiver.UUCP> <2834NU013809@NDSUVM1> <1989Oct4.141820.21930@ddsw1.MCS.COM> <111044@nstar.UUCP>
Reply-To: karl@ddsw1.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 67

In article <111044@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes:
>> Sure, some OPERATING SYSTEMS can't keep up.  That's true of VMS too, you
>> know.  386/ix, in particular, is supposed to be a real screamer (we don't
>> use it here for completely different reasons related to support).  SCO isn't
>
>Have you done any benchmarks with SCO Unix 3.2?

Not yet.  We haven't loaded it on our machine here as of yet, since we don't
have a copy for ourselves.

>> quite as fast as the hardware; I'd admit that I have a darn hard time
>> getting better than 400KB/sec out of Xenix through the raw I/O interface.
>> That is something that needs to be taken up with the software vendor.
>
>What utility are you using to benchmark disk I/O under Xenix?

"dd" to/from a raw and cooked (block) partition.  About as accurate as you 
can get for sequential I/O.  Random I/O is of course going to be worse, as 
you need to also seek the heads in that case.  The sequential checks have 
been made over several megs of data to make sure we're averaging out any 
possible inconsistancies from run to run, and are done on a quiet system
(single-user mode when possible).

>> Every one of our RLL-based machines can do in the area of 700KB/sec raw I/O.
>
>Using which WD controller?

WD1006V/SR2.  No problem at all.  We consistantly hit 650-700KB/sec.  If you
don't then your controller or machine is broken (ie: too many wait states
on the bus!) or was incorrectly formatted.

Some of our newer motherboards have been showing up with around 630KB/sec.
I got upset with this number; it's too low.  Investigation showed that these
boards had a Phoenix BIOS in them without the settable I/O wait states
(aha!).  A BIOS swap (for AMI) and re-configuration fixed 'em.

630KB/sec isn't bad!  680 is better though :-)

>> If we sell a 386 system with an RLL interface, you can bet we'll guarantee
>> that the raw I/O rate, measured with something like CORETEST (gotta define
>> the benchmark in order to be meaningful), is from 630-700KB/sec.  ESDI
>
>Every 2372 I've seen bench outs between 650-690KB/sec.  Why the WD over the
>2372?

With XENIX?  The ACB2372 we have here right now does ~100KB/sec with SCO
Xenix.  That's terrible, and is one reason we use the WD1006 series over the
Adaptec.  The WD series also has better ECC capability demonstrated on the
bench, it can recover data from marginal drives that the Adaptec will error
out on.  As an example, we have one ST4144 right here in the shop that shows 
~30 errors with our diagnostic software using the WD1006, and some 200 (!)
errors on the >same< drive using a 2372.  This is a shop drive; I'd never
put that thing in a box for a customer, but it does demonstrate the superior
data recovery abilities of the WD card.  Adaptec claims to have the best
data separation capability; they're full of hot air.  Our actual field tests 
don't bear out their claims.

You know which board I'm going to trust my data to given a choice, don't you?

There is little difference under MSDOS in speed.  Under Xenix the performance 
is worlds apart.  The data recovery bonus is icing on the cake.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"