Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!lll-winken!uunet!philmtl!philabs!linus!mbunix!rachamp
From: rachamp@mbunix.mitre.org (Richard A. Champeaux)
Newsgroups: comp.sys.amiga
Subject: Re: GVP controller
Message-ID: <63147@linus.UUCP>
Date: 8 Aug 89 15:41:30 GMT
References: <8908072207.AA14796@jade.berkeley.edu>
Sender: news@linus.UUCP
Reply-To: rachamp@mbunix (Champeaux)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 57

In article <8908072207.AA14796@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>Let me give you some insight into that. The GVP controller is actually faster
>even though you get lower diskperf times. You see, the GVP controller first
>DMA's data onto a local cache. This DMA transfer is not at full speed since
>the hard drive simply cannot read bytes that fast. Then the GVP controller
>lets the Amiga's processor read the bytes from the cache at full speed, faster
>than a DMA fdirectly from the hard disk could do it.
>
>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.

This is not necessarily true.  It goes under the assumption that the DMA 
controller (the chip itself) grabs the bus and holds onto it untill it has 
finished transferring all the bytes, even if it sits idle most of the time.
This may have been true for earlier DMA chips, but a modern, more prudent chip
would release the bus if it was not ready to transfer the next word.  Such 
action is necessary today in a world where bus speeds far exceed the speeds of
perpherials.  I don't know if the HardFrame supports this, but then I imagine
that neither do you.

Also, even if what you said was correct, the transfer rate of the GVP would
never be faster than a DMA hard disk controller.  The processor would get a
chance to do something else, yes, but that doesn't make the transfer from the
hard disk any quicker.  With the HardFrame, it would take X amount of time to
DMA the data into memory.  On the GVP it would take X amount of time to DMA
into it's onboard buffer, and then Y amount of time to copy that buffer into
memory.  Times X and Y would not be able to overlap, since the DMA chip would
be hogging the 16k onboard buffer.  Even if they could overlap, it would show
up with diskperf.

Since you refer to the CPU transfer as fast and the DMA transfer as slow, are
you implying that you think that the processor can move a byte faster than the
hard disk can provide it?  If that were the case, then non-DMA controllers 
would be just as fast as DMA controllers.  This is definitly not the case.  
DMA controllers are typically 2-4 times faster than non-DMA controllers.
Therefore, time Y above is at least as long as time X, and therefore, a DMA
controller would be at least twice as fast as the GVP.

>Now you know why
>all the CS and EE types here on Usenet recommend GVP while the doof dummkopfen
>in Deutschland recommend the rest.
>
>Valentin

I am a EE type (well actually a CE type; that's Computer Engineering), and
I don't recommend the GVP.  I owned one, was totally unimpressed, and bought
a HardFrame.  The HardFrame is giving me transfer speeds more than 3 times as 
fast as the GVP.


Rich Champeaux  (rachamp@mbunix.mitre.org)
Graduate Student working on a MS in Computer Engineering at Clemson University.
Currently at the Mitre Corporation, Bedford Mass.