Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.hardware
Subject: Re:   GVP Trade-in
Message-ID: <1153@mpirbn.mpifr-bonn.mpg.de>
Date: 1 Sep 90 14:51:55 GMT
References: <589@oregon.oacis.org> <38CP09P@dri.com> <02048.002057@thiger.UUCP> <552@DIALix.UUCP> <02123.132132@thiger.UUCP>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 46

In article <02123.132132@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes:
>the problem is: if dma-transfer from controller to fast-ram takes place,
>is the processor able to access this fast-ram at the same time?
>(may be implemented via splitting the totally available access-cycles)
>for if it is not, your processor will do ABSOLUTELY nothing, because
>it's cut off the bus (with exception of real weird programs that have
>the luck to be inside the instruction cache when dma starts and
>need no data from "outside"-world).
That's not completely correct. Neither CPU nor DMA use the full bandwidth
of the system bus. They can share the available bandwidth so that
a data transfer of 700k/s will degrade CPU peformance by only 20%.

>>At the Zorro II bus speed of about 3.5 MHz, this would
>3.5 MHz?
3.5 MB/sec !

>you have to take the bus-arbitration into consideration.
If you're doing short bursts (say 16 words at once), you won't notice
bus arbitration.

>>You can also connect
>>more than one drive without "choking" on the bus, especially during
>>overlapping seeks and transfers.
>what do you want to say here, i don't understand this.
If the SCSI bandwidth would be about 800Kb/sec you could manage the
data transfer of one disk with 800Kb/sec. If you have two disks of those
you can get 400Kb/sec from either. Now, since the bus is faster you can
multiplex the bus between the drives and get 800Kb/sec from both thus
moving 1.6MB/sec.

>1. i do not measure a controllers performance via filesystem. there
>are tests (i use speedtest, comes with all ALF-controllers) that
>measure the real device-/controller-performance ((read-)throughput).
Well, you might miss the real-world experiences then. My (OMTI-) controller
gets about 330K/sec from an RLL drive when using speedtest. But then
file system operations are using relatively small block sizes so that
I don't get anything near that except for loading single chunk executables.
You have to do something intelligent to get reasonable speeds for
regular operations besides improving the raw data transfer rate.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."