Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!unmvax!ncar!ames!ucsd!orion.cf.uci.edu!uci-ics!zardoz!tgate!ka3ovk!drilex!axiom!linus!mbunix!rachamp
From: rachamp@mbunix.mitre.org (Richard A. Champeaux)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DMA or polling (was Re: GVP controller)
Message-ID: <63241@linus.UUCP>
Date: 11 Aug 89 13:03:52 GMT
References: <8908092130.AA23369@jade.berkeley.edu>
Sender: news@linus.UUCP
Reply-To: rachamp@mbunix (Champeaux)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 81

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

You keep claiming that the transfer from the disk is slow, and the transfer by
the CPU is fast.  Have you ever bothered to calculate the speeds?

The minimum loop required for transferring words from GVP's onboard buffer to
main memory is the following:

loop:	move  (a0)+,(a1)+	(24 clock cycles)
	dbra  d0,loop		(18 clock cycles)

The execution times were found in Motorola's 68000 programmer reference manual.
So it takes 42 clock cycles to transfer 2 bytes.  At 7.12MHZ, that 5.89 us to 
transfer 2 bytes, or 339 kbytes/sec, maximum.  Assuming no transfer time from
the disk, and no track to track stepping time, the maximum transfer raste is
339 kbytes/sec.

I don't even pretend to know all of the delays and bottlenecks associated with
a SCSI drive, but lets look at the on you mentioned: the disk rpms.  Hard
disk drives, I believe, spin at 3600 rpms.  My ST296N has 34 sectors per track
with 512 bytes per sector.  It is formatted with an interleave of 1.  Assuming
that there are no other delays, the disk itself can deliver 1.04448 Mbytes/sec.
I realize that there are a bunch of other factors, but the drive rpm is not
the bottleneck.

Your argument now seems to be sitting on a pretty poor foundation.

You also claim that part of the advantage of the GVP is that the processor can
do other things while data is being transfered to the onboard buffer.  Lets
look at that.  My HardFrame is giving me 655 kbyte/sec reads.  Lets call the
time it takes to transfer a chunck of data X.  The transfer rate from GVP's
onboard buffer to main memory is roughly half that of the HardFrame, so lets
call it's transfer time 2X.  The time it takes to transfer from the drive to
the onboard buffer can not be bigger than X, so lets also call it X.  Lets
also assume that with the HardFrame, the processor can not access the bus 
durring the transfer.  

So, the time it takes for the transfer to complete on the GVP is 3X.  Durring
that time, the processor is busy 2 thirds of the time.  Durring the same time
period 3X, however, the HardFrame is busy only 1 third of the time.  So where's
this mythical free time advantage the processor is supposed to have with the
GVP?

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

Oh that's OK, don't put yourself down.  You'll do better next time.

>Valentin

Rich Champeaux   (rachamp@mbunix.mitre.org)