Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Re: A3000UX Seems Fated (Kill file alert!)
Message-ID: <17084@cbmvax.commodore.com>
Date: 3 Jan 91 22:40:51 GMT
References: <39228@nigel.ee.udel.edu> <1990Dec17.052316.19609@NCoast.ORG> <1990Dec24.220257.12208@ddsw1.MCS.COM>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 66

In article <1990Dec24.220257.12208@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes:

>This is a non-issue.  The ISA PC bus can pass 8MB of data per second.  The
>best SCSI fixed disks we have available today can do 2MB/second.  MOST disks
>cannot sustain that kind of transfer rate for long, even in synchronous
>mode.
>SCSI has a maximum transfer rate of 5MB/sec.  That is STILL well under the
>ISA bus machine's bus bandwidth.

Uh, not quite.  The ISA bus manages 4MB/s.  However, you can't actually 
achieve that without some form of true DMA.  Any CPU driven transfer is 
going to run from somewhere below 2MB/s (any 8MHz '286 system) on up, depending
on the speed of the local memory the thing has available.  Most asynchronous
SCSI drives have a peak transfer rate of 1.5MB/s.  There's a special 
asynchronous mode that manages 2.5MB/s.  Synchronous mode can go as high as
5MB/s, and under SCSI-2 that's up to 10MB/s.  

That's hardly the only issue, though, if you're also considering running 
something like UNIX on this system.  Assume a basic 1.5 MB/s SCSI drive.  On
the ISA bus, any PC is going to spend at least 40% of any given transfer
period fetching data from the SCSI bus.  That's assuming a fully buffered,
interrupt driven SCSI controller that funnels the 8 bit SCSI data into 16 bit
data for the ISA bus transfer.  You can easily approach 100% of the transfer
time with weaker SCSI card designs.  The A3000, with the same drive, spends
about 4% of the transfer time actually performing the I/O operation.  Which
gives you 96% of your CPU time to spend on other tasks, even with the drive
running at peak.  If you were just running MS-DOS or something, the two 
approaches would give you the same performance, but the former is going to
drastically bog down under UNIX, especially if you get into much paging
activity.

>Since there is little or no reason to put anything ELSE on that bus other
>than perhaps video, you have 4X the needed processor <> disk bandwidth.
>Anyone who tries to sell you more bandwidth than you need is a thief -- of
>your money, that is.

You're still thinking single-tasking.  In my opinion, anyone who makes your
whole system drop down to the speed of the SCSI bus just to do a disk transfer
is a their -- of your money and your CPU time.

>They take nearly all the load off the processor, do intelligent seek ordering, 
>overlapped command/data requests, and all kinds of other wonderful things.

Sure, you can take the load off the processor with any true DMA device, and if
you make it intelligent it can do more for you.  But on ISA there's nothing you
can do to make the DMA device and the CPU access memory at the same time.  So
while you're transferring data, you have the CPU switched off.  Again, it 
doesn't matter if you're not running a real OS, but since the only actual use
for a PClone is UNIX anyway (assuming you don't have a better platform for
UNIX), get need as much bandwidth as possible -- you can use it all.

>Today EISA is a waste of money, as is MCA.  

For MS-DOS, sure.  No arguments.  Get a real OS and the differences will be
striking.

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


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"Don't worry, 'bout a thing. 'Cause every little thing, 
	 gonna be alright"		-Bob Marley