Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!cbmvax!cbmehq!babylon!rbabel
From: rbabel@babylon.UUCP (Ralph Babel)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: HardFrame Still the Best?
Summary: Don't think so.
Message-ID: <04619.AA04619@babylon.UUCP>
Date: 26 Oct 90 12:54:59 GMT
References: <9010172027.AA03829@hamlet.acc.uncg.edu> <90297.223722IO92257@MAINE.BITNET> <6381@ethz.UUCP>
Reply-To: cbmvax.commodore.com!cbmehq!babylon!rbabel (Ralph Babel)
Lines: 142

In article <6381@ethz.UUCP> visinfo@ethz.UUCP (VISINFO c/o
Sascha Schnapka) writes:

> - Hardware: The Hardframe is still the only HD-Controller
>   with an Adaptec AIC-6250 SCSI chip

Might be true.

> that is capable of doing 2.5Mb/sec without using
> synchronous transfer.

Not true! The WD33C93A (as used by Commodore and GVP) can do
likewise! (See WD manual.)

> + 1) the limiting factor for maximum sustained throughput
>      is higher than on the WD (the latter having something
>      like 1.5Mb).

Not true! WD supports 2.5 Mbytes/sec async and 5.0
MBytes/sec sync transfer. The latter uses a 12-byte FIFO.

> + 2) the chip apparently always does some read-ahead,
>      which considerably increases overall reading-speed on
>      cheap drives, namely Seagate St-277N-1, St-296N. All
>      these drives run interleave 1 on hardframe only.
>      (Since I do no longer own such, I have not yet tested
>      them on the latest GVP)

With FFS and DMA, I can't see a problem here. Should work.

> + 3) You also get more performance with extremely
>      expensive drives having internal caches. Namely the
>      reading-speed for short files (important almost
>      anytime, namely during execution of startup-sequence)
>      is much higher with the HardFrame. The most extreme
>      case I have ever seen was with a CDC Wren VI (660Mb),
>      where the read transfer rate at a file size of only
>      4kb was about 300kb with 2091,2090 and even less with
>      the former GVP version compared to over 800kb on a
>      HardFrame.

I'm getting similar figures with an Imprimis drive and the
new GVP controller. (But I don't see how this relates to
either HardFrame or GVP - it's the clever caching scheme
that's part of the drive.)

> + 4) Some diskspeed tool I tested showed that the
>      HardFrame also has a more powerful data path from the
>      board into memory.

How is this supposed to work? HardFrame doesn't have any
on-board RAM, so it cannot take any shortcuts during DMA. If
you transfer data between the SCSI bus and GVP's on-board
RAM, however, it doesn't even use the Zorro-II bus, so you
could run yet another bus master (e.g. an Ethernet DMA card)
transferring data to some other RAM at full Zorro-II speed.
If DMA is to or from non-local RAM, GVP has to use the
normal Zorro-II DMA-protocol, of course.

>      The tool had an optional 'DMA contention' which
>      turned on all bitplanes, copper and stuff.

Who cares - as long as DMA is to and from Fast-RAM?

>      The HardFrame was the ONLY controller that did not
>      show the slightest performance degradation at full
>      load.

Of all the controllers _you_ tested ...

> - 5) You cannot use the HardFrame on the A3000

Maybe yes, maybe no.

>      (as all DMA-HDControllers)

Again: not true! What's the problem in comparing the address
mask against the lower 16-meg and - if io_Data points to
some region outside this area - doing buffered I/O to some
DMAable memory region? GVP's latest driver can even handle a
MountList mask of 0xFFFFFFFF.

>      because it does not DMA into the A3000's outside
>      24bit FAST RAM.

That's a limitation of Zorro-II.

>      Everything goes from/to Chipram and must then be
>      copied from the Buffer to the location in FastRAM
>      USING THE CPU.

So what? Having non-DMA memory in your system usually
implies that you have a fast processor. On my A2000 w/ GVP
'030, I can see almost no difference in speed when using
buffered mode vs. full DMA mode (e.g. w/ a Quantum P80S).

> - Software
>   This is the weak point of the HardFrame.

Joanne would kill you for a statement like this! :-)

> Not only is the HardFrame kind of choosy and simply does
> not accept some strange drives (like Maxtor...)

In case of the MaxTor, this is not really the HardFrame's
fault: Some MaxTors behave in a non-standard way during
startup, very similar to Seagates.

> - Microbotics are almost the only people not to support
>   A-MAX.

What about those German manufacturers?

>   I even think someone like Ralph Babel should go and make
>   a HardFrame.AMHD.

Who? Me? :-) :-) :-)

>> HardFrame and the GVP II's and the Hardframe
>> was said to be twice as fast as the GVP?
>
> That was with the old, slow version of the GVP.

It might be "slower", but I wouldn't call it "slow". It is
possible to use the new software with the old controller.

> This can no longer be claimed

Thanks!

> and either way depends on the drive you use.

That's really the problem! Nowadays, the drive is the
bottleneck - unless you spend a _lot_ of money, of course.

> Peter Simeon & F.Burgel

See you in Cologne, I guess!

Ralph

P.S.: I'm biased. (But you knew that, didn't you? :-)