Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: How FAST is FAST...
Message-ID: <6652@cbmvax.UUCP>
Date: 20 Apr 89 17:24:26 GMT
References: <8553@xanth.cs.odu.edu>
Organization: Commodore Technology, West Chester, PA
Lines: 105

in article <8553@xanth.cs.odu.edu>, manes@cs.odu.edu (Mark Manes) says:

> This is what I learned, and it makes sense to me, you hardware folks (Dave
> Haynie, you remember me, from Comdex?? No.. shame on you :-) ) tell me
> if I was fed a line.

Who, me?

> The man said that the GVP was not a true DMA controller, and because of that
> fact, it does not take the bus to itself (and suspend all other tasks while
> taking the bus) and therefore the high numbers 600k and greater are just 
> numbers, and not in fact the real transfer speed.

I really don't know what they mean by "just numbers".  I get real figures of
around 550k/sec. with my 80% full and likely fragged Quantum 80 meg drive
and my 2090A at home, so I can assure you it's possible to get 1/2 a meg or
better per second with that drive technology.  The problem is the controller,
and the reason is that it's non-DMA.

For any given word transfer, you have several things to consider.  If you
build the simplest possible controller, you have nothing more than a SCSI
chip connected to the bus.  This is slow in that data has to cross the bus
twice to get into the 68000, plus once to be put into main memory, for
each byte you read.  And there's a good chance that the SCSI chip won't keep
up with your 68000, which means you may end up waiting for it and as a 
result slowing the entire system.  Examples of this kind of device are the
C. Ltd. controller for the Amiga and all Macintosh on-board SCSI interfaces.

You can build a much smarter device that's still non-DMA with a little extra
effort.  Such a system will have dedicated logic that talks to the SCSI 
chip and effects transfers to a local section of shared RAM, without 
involving the 68000 at all.  Once a block is transferred, such a controller
interrupts it's device, which then does what's essentially a memory to
memory copy with the 68000.  While you still have to cross the bus twice
for each word transferred, you're never waiting for the SCSI device to 
be ready, and all transfers happen 16 bits at a time.

Finally, there's DMA.  A good DMA device must be resonably intelligent to
be effective.  One could conceviable take over the bus, transfer one byte
into DRAM, and then give this bus back, but that's not going to be any more
efficient than the simple polled controller in the first example.  The trick
is to buffer up a reasonably large chunk of data, which can then be transferred
directly to it's destination at full bus speed.  The buffering tradeoffs are
size and complexity vs. cost, essentially the same problem the second type of
controller has to solve.  The advantage is that for each word transferred, 
you only have to cross the bus once.  So in an ideal situation, this kind of
controller transfers about twice as fast as the one in the second example.

> He went on to say that the GVP does not experience any problems with 
> overscan (this I have confirmed, using Deluxe Paint III) because it does
> not take the bus.

Taking the bus is not what causes overscan problems.  The problem with 
deep bitplanes and overscan is that the number of cycle on the chip bus
available to ANY bus master, DMA device and 68000 alike, is reduced.  The
main reason the GVP works better in such situations than something like
the A2090 is a detail of their buffering mechanisms, not the fact that one
is non-DMA and the other is DMA.  The GVP will go and get a whole block and
save that in it's RAM before transferring, or something very similar.  The
A2090 doesn't have a large RAM, but in fact a FIFO that's less than a disk
block long.  So when transferring a block, if the A2090 can't get bus access
and dump it's FIFO, the next chunk being transferred can be missed, and the
cycle may have to be retried.  It's actually possible to build a controller
with a small FIFO that wouldn't have this problem if it knows how to wait
state the SCSI transfer, which is apparently possible but not handled by the
A2090.

> He did say that the diskperf program is good to check out newer versions
> of the driver software on the same drive.  This is a accurate test to
> tell if a new driver improves performance, no matter how bogus the number
> is.

I'm no expert on disk benchmarks, but was under the impression that the
diskperf benchmark is pretty well accepted.  It's true that any benchmark
is good for testing relative speed of the same exact hardware under the
slightly differing circumstances.  For the same reason, I use the
Dhrystone benchmark to tell me when my 68020 boards go faster.  And while
testing that same Dhrystone on another machine may not tell me the whole
picture, it does give me some valid indiciation of the performance
differences.  And while the difference in Dhrystone between a Mac II and
and Amiga 68020 machine don't tell me everything about those systems, it's
a decent appraisal of the speed I'll get from small, integer-based programs
on each of those system.  Looking at the same benchmark run on a '386
system will tell me less, but it's still an indicator.  Once I run the
same benchmark on two Amiga systems with slightly different 68020 boards,
I have a pretty specific indication of the relative integer performance of
each board; there's nothing else to change.  That doesn't necessarily tell
me how total system performance will be (maybe one board has 32 bit RAM with
DMA, and the other doesn't), or how a 500k program will necessarily compare
(maybe one board has a much slower CPU with larger cache).  

Similarly, a program like diskperf run on two different hard disk systems
is an indicator.  If you make both systems Amigas, it's a better indication.
If you use the same hard drive in both tests, you're now down to looking at
the isolated performance of each disk-driver combination.  If you just run
diskperf, you're getting a good indicator of maximum possible speed.  If
you run diskperf along with several other programs, or multiple bitplanes,
you'll get a different indication of performance.  But with hardware
matched that closely, I think it'll be a very good test.

> -mark=
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession