wizard@accsys.UUCP (Christoph Brand) (08/06/89)
In the latest intoductury posting it is said: >The GVP HardCard is heavily recommended, clearly the best of the >established third Party cards. It has been around a while, so all >the bugs are gone, but it supposedly relies upon the processor to do BULLSHIT! I threw my GVP away, since I saw that it messes up with several graphic software products, e.g. TurboSilver3.0 (animations can't be played anymore), B.A.D (doesn't work at all) and so on (however, it does not mess with standard-software like wordprocessors and spreadsheets) Also, it doesn't work with the A2620, the 68020 processor board from Commodore. Obviously from what one hears the best controller must be the HardFrame, but a) I don't know it and b) they said the same about the GVP controller. 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; I wonder what it's going to do with a Quantum drive. Anyway, when the GVP was released, everybody around here recommended it, but go ask a dealer now about it.....(of course, I don't know what they tell you in the US, but in Switzerland and Germany they tell you words about the GVP controller that are too ugly to mention here...:-) It does not mess with standard-software like wordprocessors and spreadsheets. >a lot of the work. The Quantum Drives are supposedly the Best on >the market, and is available in 28ms and 11ms types. Expect it >to last twice as long as typical drives. May require EEPROMS to >Autoboot. Now that's true. Quantum drives are superb, and VERY fast. But it depends very much on the controller, as I said, my 2090a with a slow Epson ST506 drive works AS FAST as the GVP with the Quantum...... -- --------------------------------------------------------------------------- Chris Brand Berne, Switzerland Wizard BANG: ...!uunet!mcvax!cernvax!impch!accsys!sosaria!wizard OR: ...!uunet!acad!acadch!impch!accsys!sosaria!wizard "Justice is the possession and doing of what one is entitled to" - Platon ---------------------------------------------------------------------------
swan@jolnet.ORPK.IL.US (Joel Swan) (08/07/89)
In article <437@accsys.UUCP> wizard@accsys.UUCP (Christoph Brand) writes: >In the latest intoductury posting it is said: > >>The GVP HardCard is heavily recommended, clearly the best of the >>established third Party cards. It has been around a while, so all >>the bugs are gone, but it supposedly relies upon the processor to do > >BULLSHIT! >I threw my GVP away, since I saw that it messes up with several . I'll take it... >graphic software products, e.g. TurboSilver3.0 (animations can't be >played anymore), B.A.D (doesn't work at all) and so on (however, it does I can't say about TS3.0, but I do know B.A.D. has had problems with most HD's. It certainly has problems with 40 meg partitions on both my Quantum 80S and Seagate 251-1 running WITH an A2090A. . >not mess with standard-software like wordprocessors and spreadsheets) >Also, it doesn't work with the A2620, the 68020 processor board from The incompatability problem is the fault of early ROMS used on the A2620 board, NOT GPV's board. I suggest getting your facts in order before getting too embarrassed. BTW- are the new ROMS now being used? I don't own a A2620. >Obviously from what one hears the best controller must be the HardFrame, >but a) I don't know it and b) they said the same about the GVP controller. I've heard the Hardframe had problems w/Quantum drives. This may have been fixed. Anyone care to tell? I think it had to do with prepping. >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; I wonder >what it's going to do with a Quantum drive. I've used both the GVP and A2090A (own the A2090A, used the GVP). The GVP is much easier to set up. The support from GVP is phenominal from everything I've heard (unlike some frustrating calls to CBM customer support. Thank goodness for C-A techs that help out on their own!) The A2090A still has problems with 4bp high res screens and doesn't appear to be any faster than the GVP, probably slower. The A2091 should take care of this. >Anyway, when the GVP was released, everybody around here recommended it, >but go ask a dealer now about it.....(of course, I don't know what they >tell you in the US, but in Switzerland and Germany they tell you words . There's the key. Support here has been great in NA from all reports. Maybe GVP should check up on their Europe support. It's unfortunate that one experience and a couple unknowlegeable dealers can spoil someone's thinking like this. I do hope GVP's reputation is not this bad ALL OVER Europe. Is it? >about the GVP controller that are too ugly to mention here...:-) >It does not mess with standard-software like wordprocessors >and spreadsheets. . (the artircle qouted about Quantum drives) . >Now that's true. Quantum drives are superb, and VERY fast. But it >depends very much on the controller, as I said, my 2090a with a slow >Epson ST506 drive works AS FAST as the GVP with the Quantum...... Hahahaha, hehehehe. That's all I can say. >--------------------------------------------------------------------------- >Chris Brand Berne, Switzerland Wizard >BANG: ...!uunet!mcvax!cernvax!impch!accsys!sosaria!wizard >OR: ...!uunet!acad!acadch!impch!accsys!sosaria!wizard >"Justice is the possession and doing of what one is entitled to" - Platon >--------------------------------------------------------------------------- Thank goodness most of the people reading this know better. -- -Joel E. Swan % swan@jolnet.UUCP || PLINK ID: Amiga*joel % % "Amigas.... for the rest of us." || CI$ : 74746,3240 % % "...peace with God through our Lord Jesus Christ." Romans 5:8 %
kelso@mimsy.UUCP (Stephen Kelley) (08/07/89)
In article <1267@jolnet.ORPK.IL.US>, swan@jolnet.ORPK.IL.US (Joel Swan) writes: > In article <437@accsys.UUCP> wizard@accsys.UUCP (Christoph Brand) writes: I've used the GVP I2000/2 for 8 mos & more recently the 2090A, both w/ a Q80. > I've used both the GVP and A2090A (own the A2090A, used the GVP). > The GVP is much easier to set up. The support from GVP is phenominal > from everything I've heard (unlike some frustrating calls to CBM customer > support. Thank goodness for C-A techs that help out on their own!) > The A2090A still has problems with 4bp high res screens and doesn't appear > to be any faster than the GVP, probably slower. The A2091 should take care > of this. > I agree that it's easier to talk to tech support at GVP than at CBM (any epsilon (no matter *how* small)) > 0!! As for the GVP setup... Give me a life!!! Their installation software sucks moose mucus. At the time I didn't have 1.3 roms and yet I wanted to do something as outrageous as partitioning my Q80 in something other than 2 40M partitions. Does anyone else wonder what the 1.3 roms & partitioning have do to w/ each other??? Their first disk would not allow for used defined partitions (& was actually 1.2 based) & their *new* revised software assumed 1.3 roms. In short I had to hack up both versions to do what I wanted to do. I generally *liked* the GVP (it was quite fast) but most of the performance was do to the Q80. As for design, what about MAX TRANSFER, the brain damaged cousin of Mr. Headroom. If your requests are over 8192 *watch out*. IF YOU DON'T SET THIS PARAMETER W/ gvp YOU'LL GET FILES OF THE CORRECT SIZE BUT THEY'LL BE CORRUPTED. 'Nough said? > (the artircle qouted about Quantum drives) > . > >Now that's true. Quantum drives are superb, and VERY fast. But it > >depends very much on the controller, as I said, my 2090a with a slow > >Epson ST506 drive works AS FAST as the GVP with the Quantum...... > > Hahahaha, hehehehe. That's all I can say. I now have a 2500 & w/out setcpu yet w/ the ST506 Rodime (& the 2090A) was as quick as the GVP w/ the Q80. The Q80 + 2090A w/ setcpu is *very* fast. (Thanks Dave...). -- Real: Stephen Kelley, Welch Library, Johns Hopkins Univ. Internet: stevek@welch.jhu.edu
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/08/89)
In article <18927@mimsy.UUCP> kelso@mimsy.UUCP (Stephen Kelley) writes: > >I generally *liked* the GVP (it was quite fast) but most of the performance >was do to the Q80. As for design, what about MAX TRANSFER, the brain >damaged cousin of Mr. Headroom. If your requests are over 8192 >*watch out*. IF YOU DON'T SET THIS PARAMETER W/ gvp YOU'LL GET >FILES OF THE CORRECT SIZE BUT THEY'LL BE CORRUPTED. 'Nough said? > >-- >Real: Stephen Kelley, Welch Library, Johns Hopkins Univ. >Internet: stevek@welch.jhu.edu I bought a GVP Impact2000 and used it for about 1.5 months. I wasn't too terribly thrilled. When I bought my 2000, I decided that I wanted a big and fast hard disk setup. I wanted to buy the HardFrame, but I couldn't find anyone who had them in stock. I decided to buy the GVP since I had heard good things about it, and since they were advertising it with the Quantum as being fast, I figured what the hell, it's got to at least be faster than my Supra I have on my 1000. Wrong!!! The drive I was using with the GVP is a ST296N 80Meg 28ms. The Supra was using a Miniscribe 8425S 20Meg 65ms. The Supra was giving me ~140k reads and writes, but the GVP gave me only 123k reads and 95k writes, and it had a drive that was twice as fast. Now, Amiga World and other people were reporting speeds around 240k, but I couldn't figure how to change anything. The GVP software is so easy to use because they don't let you tweak anything. You can't even change the interleave. There might have been something wrong with my setup, but I didn't see any way to change anything. I decided to chalk it up to experience, went with my first instinct and bought a HardFrame. With the same ST296N, I'm now getting 655k reads and 290k writes. The HardFrame is even cheaper. Also, if you plan to buy memory chips for the memory expansion, check with GVP first to make sure you buy the right brand. I tried to use the 150ns ones I had in my Starboard2 and they failed all over the place. They worked just fine in the Starboard2. I called GVP and they named one brand that won't work, but that wasn't what I had. They told me to ship them the board with the memory in it and they would check it out. They told me that eight of my chips were bad, and that the board worked fine. They sent me the board and the chips back, and I put the chips back in the Starboard2 and they tested fine. I've since bought an adaptor card for the Starboard2 and put in into my 2000. Appearently GVP pushed their timing too close to the DRAM specs. By the way, I still have my GVP, and I'm willing to sell it. You can buy it new with the autoboot roms for about $330 from a mail order house. I'm willing to part with it for $250. It was only used for about a month and a half. I'm willing to negotiate within reason. Rich Champeaux Currently at rachamp@mbunix.mitre.org After 8/18 - rchampe@hubcap.clemson.edu
451061@UOTTAWA.BITNET (Valentin Pepelea) (08/08/89)
Christoph Brand <wizard@accsys.uucp> 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. 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. 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. Other controllers such as the A2090 and HardFrame DMA directly from the harddrive into internal memory, thus tying up you CPU much longer. 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. Now you know why all the CS and EE types here on Usenet recommend GVP while the doof dummkopfen in Deutschland recommend the rest. Valentin _________________________________________________________________________ The godess of democracy? "The Name: Valentin Pepelea tyrants may destroy a statue, Phonet: (613) 231-7476 but they cannot kill a god." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Confucius Planet: 451061@acadvm1.UOttawa.CA
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/08/89)
In article <8908072207.AA14796@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Let me give you some insight into that. The GVP controller is actually faster >even though you get lower diskperf times. 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. > >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. Other >controllers such as the A2090 and HardFrame DMA directly from the harddrive >into internal memory, thus tying up you CPU much longer. This is not necessarily true. It goes under the assumption that the DMA controller (the chip itself) grabs the bus and holds onto it untill it has finished transferring all the bytes, even if it sits idle most of the time. This may have been true for earlier DMA chips, but a modern, more prudent chip would release the bus if it was not ready to transfer the next word. Such action is necessary today in a world where bus speeds far exceed the speeds of perpherials. I don't know if the HardFrame supports this, but then I imagine that neither do you. Also, even if what you said was correct, the transfer rate of the GVP would never be faster than a DMA hard disk controller. The processor would get a chance to do something else, yes, but that doesn't make the transfer from the hard disk any quicker. With the HardFrame, it would take X amount of time to DMA the data into memory. On the GVP it would take X amount of time to DMA into it's onboard buffer, and then Y amount of time to copy that buffer into memory. Times X and Y would not be able to overlap, since the DMA chip would be hogging the 16k onboard buffer. Even if they could overlap, it would show up with diskperf. Since you refer to the CPU transfer as fast and the DMA transfer as slow, are you implying that you think that the processor can move a byte faster than the hard disk can provide it? If that were the case, then non-DMA controllers would be just as fast as DMA controllers. This is definitly not the case. DMA controllers are typically 2-4 times faster than non-DMA controllers. Therefore, time Y above is at least as long as time X, and therefore, a DMA controller would be at least twice as fast as the GVP. >Now you know why >all the CS and EE types here on Usenet recommend GVP while the doof dummkopfen >in Deutschland recommend the rest. > >Valentin I am a EE type (well actually a CE type; that's Computer Engineering), and I don't recommend the GVP. I owned one, was totally unimpressed, and bought a HardFrame. The HardFrame is giving me transfer speeds more than 3 times as fast as the GVP. Rich Champeaux (rachamp@mbunix.mitre.org) Graduate Student working on a MS in Computer Engineering at Clemson University. Currently at the Mitre Corporation, Bedford Mass.
ckp@grebyn.com (Checkpoint Technologies) (08/09/89)
In article <8908072207.AA14796@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > >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. Other >controllers such as the A2090 and HardFrame DMA directly from the harddrive >into internal memory, thus tying up you CPU much longer. > >So if you multitask a lot, you'll want the GVP controller, otherwise the other >controllers are for you. Facts are sound - but the conclusion is backwards! On such as a HardFrame or A2090, the controller moves data *directly* into the data's final resting place, using one bus cycle per 16 bit word. With the GVP, the data moves into the controllers on-board RAM using no bus cycles, but then the CPU must move the data to it's final location, using *6* bus cycles (four for the 68K instructions moving the data, and two for the data, one coming from the controller RAM and one going to the task buffer) for each word. This means that a DMA controller is *less* taxing of the CPU during a transfer than a non-DMA controller like the GVP. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
wizard@sosaria.UUCP (Chris Brand) (08/10/89)
In message <1267@jolnet.ORPK.IL.US> Joel E. Swan writes: >I can't say about TS3.0, but I do know B.A.D. has had problems with most >HD's. It certainly has problems with 40 meg partitions on both my Quantum >80S and Seagate 251-1 running WITH an A2090A. Well, I know nobody with any problems with BAD except myself when I had the GVP controller. I just installed a Seagate ST157N and it works all fine. >The incompatability problem is the fault of early ROMS used on the A2620 >board, NOT GPV's board. I suggest getting your facts in order before >getting too embarrassed. BTW- are the new ROMS now being used? I don't Another one of these human beings that obviosly ALWAYS knows EVERYTHING AT ONCE and who is NEVER wrong.... Were you never in the situation of just not having a specific information? Believe me, I read a lot of computer magazines, and it's not my fault if they write something that's not true or that's no longer true. I didn't hear of this bad ROMs neither in a BBS nor elsewhere.... not even from the german or swiss main dealer for GVP products. >I've used both the GVP and A2090A (own the A2090A, used the GVP). >The GVP is much easier to set up. The support from GVP is phenominal ^^^^^^^^^^^^^^^^ >from everything I've heard (unlike some frustrating calls to CBM customer >support. Thank goodness for C-A techs that help out on their own!) >The A2090A still has problems with 4bp high res screens and doesn't appear >to be any faster than the GVP, probably slower. The A2091 should take care >of this. Support from GVP? What's that? When I set up the GVP I found out that the install software had several bugs. In the end, I had to do everything by myself, and since the GVP Installation Software (at least the one I got) uses about a million batch-files, it was a horribly boring job of figuring out what every one does. With the Commodore software I had no problems at all, well except one, there is obviously a mistake in the Reserved=x entry in the RES2: mountlist entry. I absolutely prefer Prep to the GVP stuff! >There's the key. >Support here has been great in NA from all reports. Maybe GVP >should check up on their Europe support. It's unfortunate that one experience >and a couple unknowlegeable dealers can spoil someone's thinking like this. >I do hope GVP's reputation is not this bad ALL OVER Europe. Is it? It is not true that ONE experience spoiled my thinking. But if you get reports from your friends as well as several well known dealers (who also build excellent videohardware, so I guess they *are* quite competent) you can't just say 'They're all wrong.' But you're right, there are far too much incompetent dealers, e.g. the german main dealer for GVP products is just a joke. Try to ask a question there that is more complicated that 'Where do I have to turn on my Amiga' and they can't answer it. If GVP supports customers really as good as you say, they really should think about branch store in Europe..... >>"Justice is the possession and doing of what one is entitled to" - Platon >Thank goodness most of the people reading this know better. What do you mean by that?? Are you some kind of Thrasymachos? I hope I didn't make a mistake translating it...the german sentence is not so easy to translate.... > % "...peace with God through our Lord Jesus Christ." Romans 5:8 % Thank goodness most of the people reading this know better. ;-) Chris -- --------------------------------------------------------------------------- Chris Brand Berne, Switzerland Wizard BANG: ...!uunet!mcvax!cernvax!impch!accsys!sosaria!wizard OR: ...!uunet!acad!acadch!impch!accsys!sosaria!wizard SHORT: wizard@sosaria.ccs.imp.com "Justice is the possession and doing of what one is entitled to" - Platon ---------------------------------------------------------------------------
wizard@sosaria.UUCP (Chris Brand) (08/10/89)
In Message <8908072207.AA14796@jade.berkeley.edu> Valentin Pepelea writes: >Let me give you some insight into that. The GVP controller is actually faster >even though you get lower diskperf times. You see, the GVP controller first >DMA's data onto a local cache. This DMA transfer is not at full speed since Yeah, I know that. BUT - if writing a 3.5 MB zoo-File takes me with the GVP x seconds and with my 2090A with the ST506 drive ALSO x seconds and with my 2090A with my new Seagate ST157N 3/4x seconds, my choice concerning speed is quite clear. Beside that - directory scan goes about 2 times faster using my 2090A. >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 ... >So if you multitask a lot, you'll want the GVP controller, otherwise the other Hmm...I'll check that out. But you know, for me it is not important which controller work better in theory but which one actually does a better job while using it. I never marked any more slowdown in multitasking when using the 2090A, and I use multitasking a LOT. >all the CS and EE types here on Usenet recommend GVP while the doof dummkopfen >in Deutschland recommend the rest. Well, I agree that there are many 'doofe Dummkvpfe' (stupid fools) in Germany (as everywhere in the world), but not all are like this. Remember, they brought us the A2000. Chris -- --------------------------------------------------------------------------- Chris Brand Berne, Switzerland Wizard BANG: ...!uunet!mcvax!cernvax!impch!accsys!sosaria!wizard OR: ...!uunet!acad!acadch!impch!accsys!sosaria!wizard SHORT: wizard@sosaria.ccs.imp.com "Justice is the possession and doing of what one is entitled to" - Platon ---------------------------------------------------------------------------
balzer@frambo.enet.dec.com (Christian Balzer) (08/11/89)
[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 <wizard@accsys.uucp> 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. - <CB> 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. -- _ _ / / | \ \ <CB> 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/
jms@tardis.Tymnet.COM (Joe Smith) (08/11/89)
In article <12254@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <8908072207.AA14796@jade.berkeley.edu> (Valentin Pepelea) writes: >>So if you multitask a lot, you'll want the GVP controller, otherwise the other >>controllers are for you. > > Facts are sound - but the conclusion is backwards! On such as a >HardFrame or A2090, the controller moves data *directly* into the data's >final resting place, using one bus cycle per 16 bit word. With the GVP, >the data moves into the controllers on-board RAM using no bus cycles, >but then the CPU must move the data to it's final location, using *6* >bus cycles (four for the 68K instructions moving the data, and two for >the data, one coming from the controller RAM and one going to the task >buffer) for each word. What about DMA overhead? It takes some bus cycles to start DMA (the device has to get a Bus Grant signal), and non-zero time to stop DMA (release the bus). If you have an extremely fast disk, the controller could grab the bus, squirt all the data into RAM, and beat the pants off any controller that uses the CPU to copy data. But, unfortunately, most disks don't have data transfer rates that match the Amiga's raw bus speed. So, what do you do with DMA and a slower disk? A) Transfer the data as a single DMA request, locking the CPU out until the last byte is transfered. (slows down or stops CPU intensive tasks) B) Transfer one word at a time, allowing the CPU to run between consecutive pairs of bytes from the disk. (CPU eaten up by DMA requests and grants) C) Transfer data to cache on controller, let CPU copy to RAM via a program loop (read data into CPU, write from CPU, fetch opcodes, branch) D) Transfer data to cache on controller, let DMA hardware copy complete buffer of data to RAM at full bus speed using a single DMA request. Option D produces is the least taxing on the CPU, and is the most expensive. As for option C (which is what I interpret Valentin's remarks as advocating), you will get more usable CPU time if the transfer rate from the disk is slower than the speed of the program loop. Again, this is true if the elapsed time for CPU to transfer data from RAM to RAM is less that the elapsed time DMA grant + DMA transfer + DMA release. Summary: If the disk speed does not match the memory bus speed, CPU assisted transfers may be better than simple DMA transfers. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
ckp@grebyn.com (Checkpoint Technologies) (08/12/89)
In article <501@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > >What about DMA overhead? It takes some bus cycles to start DMA (the device >has to get a Bus Grant signal), and non-zero time to stop DMA (release the >bus). If you have an extremely fast disk, the controller could grab the >bus, squirt all the data into RAM, and beat the pants off any controller that >uses the CPU to copy data. But, unfortunately, most disks don't have data >transfer rates that match the Amiga's raw bus speed. Getting a DMA device on and off the bus is a lot less expensive than you make it sound - more like a clock cycle or two, not several *bus* cycles (which are at least 4 clock cycles each). And certainly nobody would build a DMA controller that wouldhog the bus for the duration of a transfer, given the speed hard disks move the data. > >So, what do you do with DMA and a slower disk? > A) Transfer the data as a single DMA request, locking the CPU out until > the last byte is transfered. (slows down or stops CPU intensive tasks) > B) Transfer one word at a time, allowing the CPU to run between consecutive > pairs of bytes from the disk. (CPU eaten up by DMA requests and grants) > C) Transfer data to cache on controller, let CPU copy to RAM via a program > loop (read data into CPU, write from CPU, fetch opcodes, branch) > D) Transfer data to cache on controller, let DMA hardware copy complete > buffer of data to RAM at full bus speed using a single DMA request. > Well, as it happens, the Commodore A2090(a) has a 64 byte FIFO. This is not a hole sector buffer, but the principle is the same - disk data enters the FIFO buffer, thenis transferred to memory in short DMA bursts. The HardFrame DMA controller also has a FIFO buffer, I don't know exactly how large, but the idea is the same. And the speed is greater than would be produced by transferring the entire sector into the buffer first, then into RAM, because of the overlap between disk data to FIFO and FIFO to RAM. Another wrinkle is that a SCSI disk drive *must* contain it's own sector buffer. This is because the SCSI controller must read the entire sector locally to perform ECC error correction, and then present corrected data to the host. So it's not unreasonable to think that the data presented across the SCSI interface would be moving much faster than the data appeared from the disk drive. >Option D produces is the least taxing on the CPU, and is the most expensive. But the final argument is for CPU performance degradation. You say yourself that option D provides the least CPU overhead; well, it happens to be the option all DMA controllers provide (but with FIFO rather than cache). If you look, the DMA controllers are not that much more expensive than the non-DMA controllers (the A2090 is anexception, but it also offfers an ST506 interface, which accounts for the extra cost.) -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/12/89)
Wrong. Everyone does it this way, ie. 2090A, VME boards.. all the good boards use FIFO's and DMA circuitry, with the exception of some AWESOME VME boards that have 2M of ram and 68020's on them... but anyways.. 1. wait for 1/2 full mark 2. start DMA transfer 3. transfer like heck till empty 4. suspend DMA transfer 5. goto 1 Example, the FIFO is 64 bytes, the disk is transferring 1 byte every 3500ns. The CPU can get a byte every 520ns. Nothing happens till fifo hits 32bytes. A DMA request is made at this point, and takes ~9 cpu cycles = 4680ns. During that time, an extra 1.3 bytes arrive. Now, the processor start to unload, while the disk drive is still filling it. 520ns * 1 word (2090 does words, some do bytes) * 16 words = 8320ns. During that time 2.3 bytes arrive. So transfer another 2 bytes arrive from the disk, that's 520ns. So, 8320+520 = 8840ns, during which 17 words were sent into the Amiga. Now, the DMA cycle ends, which takes ~4 cpu cycles. Now the fifo chip starts to fill up again. Each DMA cycle took 520ns, which is the fastest that you can transfer data on the Amiga BUS, because that's how a 68000 ~8MHz bus operates. Thus, to transfer 512 bytes = 256 words * 520ns = 256+some more cycles = 133120+ns of cpu cycles. During this time, the CPU is dead. Of course, the entire sector takes 1792000ns to arrive. But the difference in time CAN be used by the cpu. Now, the alternative is to use the cpu to transfer the data. In this case you have the following. The data gets into a 512byte fifo on the controller board, and the processor gets an interrupt that the fifo is full. Well, it's not gonna poll it, is it? So, it has to go get the data now. Oh yeah, we should count the interrupt latency (the time to actually get to the right code that copies the data out of the fifo into ram, which is NOT insignificant compared to my 256+ max 50 bus cycles. Then you have to execute lots of bus cycles to copy the data. If you have a 68010 which has the fancy loop mode, and if you use that, you can BEGIN to do about 3 times the work that the DMA does. You can check this with cycle timings in a 68000 book about anywhere. A 68010 will do better, in loop mode, and a 68020 will do better again, but not by near as much as you would think. In fact I suspect there might not be a difference of more than 3% between the 68010 and the 68020. I have designed a SCSI port for a VME board that is not built yet, but is capable through the use of large FIFO's (8K long) of probably 3M/sec. There are devices that can get data that fast. If you had a Conner SCSI drive with a cache on it, or one of the new Maxtors, the SCSI drive can download from the cache at incredible speeds. I suspect the 2090 (2.5M/sec max) cannot load it's FIFO (~80ns cycle time I think) fast enough to keep up to it. With a SCSI drive, any of the newer than 2 year ones anyways, the drive spin time is NOT a factor. You issue a command to the SCSI drive, and then disconnect from the device. The device has a cache on it. It gets the first bunch of stuff. Then it reconnects to the controller. It starts sending data as fast as you/it can handle it, through an async protocol. As it's doing this, it's loading the next stuff into the fifo allready. These drives go like spit. The end result is that if you request a big block from your hard drive, you will spend your entire time with the processor trying to keep your fifo clean, while the DMA will be able to do that three times as fast. IF you could go that fast. I have a databook for a Maxtor scsi, an earlier model actually. The thing has two 8 bit processors (Z8 & i8031), a dual port ram, more than 32K of rom, and a bunch of dma circuitry as well. It's more bloody complicated than a simple DUMB NONDMA controller you might want to put in your Amiga. <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
balzer@frambo.enet.dec.com (Christian Balzer) (08/14/89)
[This final posting from me on this topic is cross-posted to both c.s.a and c.s.a.t since this thread has randomly surfaced in both groups.] I believe that from a technical point of view, this discussion is at it's conclusion. Dave Haynie did a much more comprehensive description of the way the 2090 works than me, and Joe Smith did a nice summary in comp.sys.amiga. In article <8908102227.AA12223@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) writes... >YASR. (Yet Another Stupid Remark) I never claimed that transfering data using >the CPU was faster than DMAing. Merely that a DMA directly from the hard disk >was limited by the hard disk's mechanical limitations. Indeed, you didn't. I'm sorry. My remark was probably caused by the way thesentence I replied to was constructed and the fact that you stated several times that the A2090 and HardFrame do direct DMA from the HD (which they don't) and thus cause more CPU/bus usage (which they don't) and are slower than the GVP (which they aren't). I also stated in my last post that there are a number of drives which would even with a "simple" DMA solution be able to keep up with the Amiga bus. >What is wrong, deserves many flames. What is debatable deserves, respect and >counter-rebuttals and challenges. IMHO, what is wrong, deserves correction. Flames should be avoided or reserved for severe incidents. To err, is after all, human. Extensive flaming in a newsgroup will drive both the audience and potential posters away, with the notable exception of alt.flame. :-) On the topic of flaming and global/personal insults I would like to get some things straight. I reacted on Valentins remarks the way I did because: a) There was no sign it was meant as a humorous remark (i.e smiley). b) I'm a firm believer in human rights, that noone should be judged on the basis of race, religion, nationality, etc. Remarks like Valentins set off a triger in my head that sometimes can't be controlled. My reaction was in no way (subconscious urges excluded) connected to the fact that Valentin picked Germans as target for his remarks. In fact, I was at that time thinking about an appropriate reply for Frank Kuan's "don't buy at Jews" tirade, but found that Dennis M. O'Connor and Bruce Becker did beat me to it. And no, I'm no Jew. Valentin writes: > If you bloddy idiot had followed up the thread carefully, you would have > realised I was talking about a small group of Swiss and German dealers > which underrated some products in favor of others. Yes, I followed the thread. Others may have not done so. That's why I feel it's so important to either get a definition 100% straight or incorporate some "safety measures", like a smiley. ;) > While I am willing to accept rebuttals and and challenges from > anyone, I am not willing to let skitsophrenic imbeciles spit beer > flavored saliva at me like that. I constructed my semi-flame very carefully to make clear that insults based on nationality or local customs aren't "working" to well. I firmly believe that the people who know me personally or thru extensive Email exchange don't think of me in Valentin's terms. And yes, I enjoy irony, being ironic and drinking beer. And no, I don't spit nor write postings while being intoxicated. (Drinking and Hacking, they just don't mix) ;-) I waited two days before writting this follow-up and tried very hard to keep out anything that could set off more wildfires. If one still feels the need to continue any insults, please do so via EMail or in alt.flame. Thanks. Regards and farewell to this thread, - <CB> -- _ _ / / | \ \ <CB> 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/ "You have to learn to pace yourself - PRESSURE!" -Billy Joel
michael@maui.cs.ucla.edu (michael gersten) (08/19/89)
In article <1701@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: > >With a SCSI drive, any of the newer than 2 year ones anyways, the drive >spin time is NOT a factor. You issue a command to the SCSI drive, and then >disconnect from the device. The device has a cache on it. It gets the first >bunch of stuff. Then it reconnects to the controller. This is a good point. What controllers for the amiga support both bus arbitration (multiple computers/initiators on the same cable) and bus selection/disconnect/reconnect? I.e., I want to be able to have a read going on one drive while another drive is busy writting (both on my amiga), while a third drive is in the middle of a command for the other computer. Later, the programs can exchange data over SCSI--or am I hopelessly dreaming? Michael