Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!csd4.csd.uwm.edu!mailrus!cornell!uw-beaver!ubc-cs!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DMA or polling (was Re: GVP controller)
Message-ID: <692@lpami.wimsey.bc.ca>
Date: 9 Aug 89 11:31:14 GMT
Lines: 78
To: van-bc!rnews

In <8908092130.AA23369@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>Steve -Raz- Berry  writes in <120232@sun.Eng.Sun.COM>
>
>> In article <8908072207.AA14796@jade.berkeley.edu> 451061@UOTTAWA.BITNET
>>  (Valentin Pepelea) writes:
>>
>> >The net result is that the processor therefore spends less time on the data
>> >transfer and is available more often for other concurrent tasks.
>> >Unfortunately this means that there are two transfers occurring, a slow
>> >DMA from hard disk to the cache, and a fast CPU transfer from the cache
>> >to internal memory. Other controllers such as the A2090 and HardFrame DMA
>> >directly from the harddrive into internal memory, thus tying up you CPU
>> >much longer.
>>
>>       Yikes! I'm sorry, but I TOTALLY disagree with you on this one.
>> Logicly, if you look at the time to complete a given task, based only
>> on the number of bus cycles it takes to transfer a given block of data,
>> DMA will always win. Period. Unless of course your DMA circuitry is
>> totally braindead.
>
>Clearly you don't understand, or perhaps I did not explain well. The bottleneck
>here is the speed at which the hard disk turns, and therefore the rate at which
>data is available to the DMA channel.

No, it's you who do not understand. Clearly, you don't have the faintest idea
of how the 2090A works. The speed of the data coming off the disk is the same
(given the same disk drive) in all cases, and given a sufficiently small amount
of data so that things like MaxTransfer do not come into play.

>That is why DMAing directly from the hard disk to internal memory is a loosing
>proposition.  GVP provides a cache into which it reads from the disk while
>leaving the Amiga's 680x0 alone.  Only then does it transfer the data from the
>cache into internal memory at full speed, without having to wait for the
>mechanical limitations of the hard disk.

The 2090 waits for the mechanical limitation of the dard disk, yes, but it most
definitely does NOT hang on to the bus for the entire time. It has a FIFO that
fills from the HD, and that empties in small bursts. The effect of this is that
the data comes in to the FIFO at a fixed rate, that being exactly the same rate
as the cache on the GVP, and it is in the unloading of the data into main
memory where the 2090 comes out a resounding winner over the GVP. The only time
it does not come out a clear winner is in the case where multiple sectors are
being transferred and there is a lot of contention from other DMA sources. In
this case, the 2090 has to retry because of data overruns.

I have yet to play with or study a HardFrame, so I cannot vouch for its method
of transfer, but since it is as fast or faster than the 2090, I can only assume
they did it right.

>Perhaps it should then DMA from its cache into internal memory, but that is
>another question. Even if it did that, it still would get lower diskperf's than
>the A2090 or HardFrame. The improvement would be rather limited, and the cost
>would be higher. The GVP controller is expensive enough as it is.

Yes, perhaps they should, but they don't. That, and the necessity for
specifying a low MaxTransfer value are what makes the thing a comparative slug.
Check out the 2090A and the HardFrame first, then repost your perceptions.
There will be a quiz. :-)

>> Sorry, this is one EE type that
>> just won't believe it. The Amiga is a DMA machine, that is part of
>> what gives it it's amazing speed for graphics and sound.
>
>Obviously some EE types are better than others. Good luck on your '030
>accelerator design.

A rather unfortunate choice of parting shot, wouldn't you say? You've been a
tad cranky lately Valentin. Mellow out willya?

-larry

--
"So what the hell are we going to do with a Sun?" - Darlene Phillips -
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+