Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!cbmvax!cbmehq!cbmger!danube!thiger!skraw
From: skraw@thiger.UUCP (Stephan von Krawczynski)
Newsgroups: comp.sys.amiga.hardware
Subject: Re:   GVP Trade-in
Message-ID: <02123.132132@thiger.UUCP>
Date: 21 Aug 90 16:51:32 GMT
References: <589@oregon.oacis.org> <38CP09P@dri.com> <02048.002057@thiger.UUCP> <552@DIALix.UUCP>
Organization: THIndustries Software Development
Lines: 97

>In article <552@DIALix.UUCP> bernie@DIALix.UUCP (Bernd Felsche) writes:
>In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes:
>[previous ref deleted]
>
>DMA is an advantage because the CPU can be doing other (real
>processing) things.

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

>>i have never understood this one. what do they mean? 4MBytes/sec?
>>i have never seen a controller/hd-combination reaching this.
>
>4MB/SEC is the peak transfer rate on most SCSI-2 controllers which
>are not bound by arbitrary design constraints.  Whether or not GVP
>can get the data into the Amiga's RAM that quickly is another
>matter.

in fact, this is THE matter. what does it help if the data bursts in from
your harddisk and the controller isn't able to put it to your mem
(somehow). 


>At the Zorro II bus speed of about 3.5 MHz, this would

3.5 MHz?

>consume more than 50% of the available bus time... although the time
>to transfer will be a lot shorter than via polled (CPU) transfer.

you have to take the bus-arbitration into consideration.

>>4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an
>>absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a
>>standard amiga - NO processor-card installed)
>
>I know of controller/hd combinations which have _sustained_
>throughput rates of over 2MB/sec (not Amigas, workstations), with

we're talking of amigas and amiga-hd-controllers here. of course
there ARE other computers reaching it.

>By designing for 4MB/sec, GVP is doing the right thing,

do they really do that? they don't reach it, and as long as they do
not, how can you say?

>because the
>bottleneck is the hard disk (at the moment).

that's right.

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

>Another consideration is the speed of the filesystem.  AmigaDOS
>isn't exactly renowned for filesystem performance, even with FFS.

i know this.

>It involves significant CPU cycles to convert the raw SCSI data into
>something which DOS presents to the user (FFS is a _lot_ better than
>the original FS).

sorry, this is wrong. ffs doesn't convert ANY data (<-DATA). in fact,
it doesn't handle with the data at all (normally). this is one major
reason why ffs is quite a bit faster than ofs (which has to copy
the data).

>When you measure the average transfer speed, the
>filesystem (and trackdisk.device) get in the way and give you a
>distorted view of what the hardware _can_ do under ideal
>conditions.

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

2. how do you get to trackdisk.device? has absolutely nothing to do
with harddisk.

>bernie

--
best regards, 
stephan von krawczynski 

UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw
PHONE: +49 9938 1664
FAX  : +49 9938 1598