Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!decwrl!shlump.nac.dec.com!frambo.enet.dec.com
From: balzer@frambo.enet.dec.com (Christian Balzer)
Newsgroups: comp.sys.amiga
Subject: Re: GVP controller
Summary: Don't believe him (or me for that matter :-)
Keywords: Spam, stoopid(tm)
Message-ID: <4004@shlump.nac.dec.com>
Date: 10 Aug 89 19:38:06 GMT
Sender: news@shlump.nac.dec.com
Organization: DEC SWAS Frankfurt/W.Germany
Lines: 114


[Are there moron line-eaters, too?]

And once more our loony computer nerd is faced with an article of such
intense incompetence and stupidity that drives his mind instantly into
it's Mr. Hyde state and won't allow him to write a more sensible
response. Sorry!

In article <8908072207.AA14796@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) writes...
>>Christoph Brand  writes in Message-ID: <437@accsys.UUCP>
>> 
>> I use now a 2090a, and I don't have ANY problems with it; even with a
>> normal ST506 drive, it is AS FAST as the GVP with a Quantum 40S;
>Let me give you some insight into that. The GVP controller is actually faster
>even though you get lower diskperf times.                              ^^^^^^ 
                     ^^^^^
Hah, can you say contradiction? Gee, I thought so.

>You see, the GVP controller first
>DMA's data onto a local cache. This DMA transfer is not at full speed since
>the hard drive simply cannot read bytes that fast. Then the GVP controller
 ^^^
>lets the Amiga's processor read the bytes from the cache at full speed, faster
>than a DMA fdirectly from the hard disk could do it.

While pushing my blood pressure to unknown limits, you also don't fail to
give me some of the best laughs I had for quite a while.
What is "the" hard drive? I know of hard drives that can overload any DMA
controller available for the Amiga today. 
And don't try to tell us that black is white. A dedicated DMA chip will do a
MUCH better job transfering data than a 68000. That's why there is a blitter
in the Amiga, bub.

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

This is more or less correct and nice design to minimize CPU usage. However
the CPU still has to shuffle all the data around, not a nice thing to do.
GVP's CPU usage is much lower than ie the old Cltd controller or IBM
controller kludges, but it's still considerably higher than that of the
A2090.

>Other controllers such as the A2090 and HardFrame DMA directly from the
>harddrive into internal memory, thus tying up you CPU much longer.

Bullshit, at least for the A2090. It uses a 64 byte large FIFO cache that's
filled with data from the HD. When it's half full, DMA starts and transfers
the data to it's destination in RAM. The whole bus arbitration is done very
efficient and to quote the A500/A2000 Technical Reference manual, "This
amounts to only 17% over for CPU and other bus masters". What this somewhat
arkward sentence is trying to tell us is that for about 17% bus usage you get
your data delivered to it's destination at a very high speed. Although the
CPU and bus is free while the GVP fills it's onboard cache (8 KB of static
RAM if I remember correctly), the CPU and thus the bus are tied up 100% while
the data is transfered into the system. Since all my data and numerous tests
prove that the A2090 is about twice as fast as the GVP (using the same HD, of
course), you can easily calculate how much CPU/bus bandwith is used by either
controller. Take a look at Perfmon the next time you do a test.

From the performance and "feel" of the Hardframe it might do something
like the A2090. Anybody out there who's able to shed some light on this?

>So if you multitask a lot, you'll want the GVP controller, otherwise the other
>controllers are for you. Retry the diskperf benchmark again with a few CPU
>intensive programs in the background, you'll see what I mean. 

Yeah, just do that and you'll see his fantasies blown right out of the water.
I keep on wondering just how much GVP is paying him for this. Or is he
rambling on his spare time? ;-)

On a more technical side, Valentin has descriped the way the GVP controller
works quite correctly. But the conclusion he draws from this knowledge are
VERY debateable. For more infos, see my next HD controller review in a few
weeks. 

>Now you know why all the CS and EE types here on Usenet recommend GVP while
>the doof dummkopfen in Deutschland recommend the rest. 
                                                        ^^^^^^^^
                                      SEVERE LACK OF SMILIES DETECTED!!! 

Gee, this seems to be the week for for all the morons and bigots to surface.
First that "don't buy at jews" jerk (sounds awfully familiar) and now this.
And get your fucking lingo straight, before you start insulting complete
nations.
While I have no doubt that the average German is at least as stupid as the 
average Canadian, calling your fellow Canadians moronic lumberjacks will
definitivly _not_ do them justice. I'm glad that your country is also home to
people like Larry Phillips and not just crap like you. And since this doesn't
belong into c.s.a, I'll shut up now.

Are all you "CS and EE types" here on UseNet going to take this slander on
your competence unchallenged?

Inflammatory followups via EMail or in alt.flame alone. 
Let's keep at least the flames out of comp.sys.amiga, before it turns into
another alt.sex... 

I'd prefer to give my usual regards, but this time I'm just to mad.

- 

P.S.

On the topic "attitude of net.experts", I'll have to agree with Valentin
(ugh). I usually give advice via email and restrain myself to answer only
those questions I feel to be competent enough to do so.

--  _  _
 / /  | \ \   aka Christian Balzer  - The Software Brewery -         //
< <   |-<  > decwrl!frambo.dec.com!CB | unido!decum!frambo.dnet!CB      //
 \ \_ |_/ /  I-Net: CB@frambo.enet.dec.com | E-Net: FRAMBO::BALZER  \\ //
------------ PMail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G.   \X/