Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!Radagast
From: Radagast@cup.portal.com (sullivan - segall)
Newsgroups: comp.sys.amiga
Subject: Re: Re: A3000UX Seems Fated (Kill file alert!)
Message-ID: <37635@cup.portal.com>
Date: 6 Jan 91 05:36:30 GMT
References: <139982@pyramid.pyramid.com>
Distribution: na
Organization: The Portal System (TM)
Lines: 98

>>
>>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?
>
(I just finished designing a PC card, so I feel reasonably qualified to 
answer some of your questions.  I should say though, that my end of the 
development, was mostly on the card, and not on the bus, so this information
is really what I've gleaned from my co-developer while the design was in
progress.)

The ISA bus doesn't support multiple bus masters, so to get something into
motherboard memory, you have to go through the CPU in some way shape or 
form.  This makes a true DMA card impractical since you'd only be able to 
DMA to card memory, and that would not be addressable in 8088 mode, since 
all of the addressable memory of the 8088 is already allocated (and on
the motherboard, or in display cards.)  


>>                                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?
>
No, because the CPU is intricately involved in the transfer.  Actually,
I can't think of any OS that doesn't do what you are describing above to
some degree or another.  During a disk transfer under amigados, the task
waiting on input has to wait for the entire transfer to complete.  On the
other hand, since the CPU isn't involved in the transfer, it is free to 
run other (CPU bound) tasks, (like the task scheduler.)

For an IBM running UNIX, you could run other tasks during the latency 
time, but during the transfer the CPU is required to do the copying.  Not
very noticeable when only one task ik 
LC~?~?~?~?~?ik is running, but Fk~?~?~?~?~?~
>>                                                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 orderin
g
>, 
>>>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 i
f
>>you make it intelligent it can do more for you.  But on ISA there's nothing y
o
>u
>>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