Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!decwrl!nsc!pyramid!telam
From: telam@pyrps5.pyramid.com (Thomas Elam)
Newsgroups: comp.sys.amiga
Subject: Re: Re: A3000UX Seems Fated (Kill file alert!)
Message-ID: <139982@pyramid.pyramid.com>
Date: 5 Jan 91 06:10:24 GMT
Sender: daemon@pyramid.pyramid.com
Organization: Pyramid Technology Corporation, Mountain View
Lines: 85

In article <17084@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>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.

Why is this, Dave?  Because you are talking about a non-DMA design?
Could the ISA bus-based PC spend less than the 40% by using a DMA design?

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

Because MS-DOS (or at least the non-interrupt-driven processing) just
initiates the transfer then just spins in a loop waiting for the
transfer to complete?  Is that the way the PC's BIOS works?  If so, I
guess a getc() (get character) function would have to wait for a whole
block to be read before returning a single character, correct?

>                                                but the former is going to
>drastically bog down under UNIX, especially if you get into much paging
>activity.

Because it couldn't do its normal thing of scheduling another process,
right?

[deletion]

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

By "the same time," you mean upon demand, right?  In other words, the
CPU would be running in the scheduler or in another task (process),
merrily accessing memory upon its demand, until the DMA has a word or
burst to transfer, upon which it grabs the bus from the CPU and does
the transfer.  Right?

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

[deletion]

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

I really appreciate your explanations, Dave.  If I could get you to
answer these questions I have, I would feel almost enlightened!

Tom Elam