daveh@cbmvax.UUCP (Dave Haynie) (04/21/89)
in article <8553@xanth.cs.odu.edu>, manes@cs.odu.edu (Mark Manes) says: > This is what I learned, and it makes sense to me, you hardware folks (Dave > Haynie, you remember me, from Comdex?? No.. shame on you :-) ) tell me > if I was fed a line. Who, me? > The man said that the GVP was not a true DMA controller, and because of that > fact, it does not take the bus to itself (and suspend all other tasks while > taking the bus) and therefore the high numbers 600k and greater are just > numbers, and not in fact the real transfer speed. I really don't know what they mean by "just numbers". I get real figures of around 550k/sec. with my 80% full and likely fragged Quantum 80 meg drive and my 2090A at home, so I can assure you it's possible to get 1/2 a meg or better per second with that drive technology. The problem is the controller, and the reason is that it's non-DMA. For any given word transfer, you have several things to consider. If you build the simplest possible controller, you have nothing more than a SCSI chip connected to the bus. This is slow in that data has to cross the bus twice to get into the 68000, plus once to be put into main memory, for each byte you read. And there's a good chance that the SCSI chip won't keep up with your 68000, which means you may end up waiting for it and as a result slowing the entire system. Examples of this kind of device are the C. Ltd. controller for the Amiga and all Macintosh on-board SCSI interfaces. You can build a much smarter device that's still non-DMA with a little extra effort. Such a system will have dedicated logic that talks to the SCSI chip and effects transfers to a local section of shared RAM, without involving the 68000 at all. Once a block is transferred, such a controller interrupts it's device, which then does what's essentially a memory to memory copy with the 68000. While you still have to cross the bus twice for each word transferred, you're never waiting for the SCSI device to be ready, and all transfers happen 16 bits at a time. Finally, there's DMA. A good DMA device must be resonably intelligent to be effective. One could conceviable take over the bus, transfer one byte into DRAM, and then give this bus back, but that's not going to be any more efficient than the simple polled controller in the first example. The trick is to buffer up a reasonably large chunk of data, which can then be transferred directly to it's destination at full bus speed. The buffering tradeoffs are size and complexity vs. cost, essentially the same problem the second type of controller has to solve. The advantage is that for each word transferred, you only have to cross the bus once. So in an ideal situation, this kind of controller transfers about twice as fast as the one in the second example. > He went on to say that the GVP does not experience any problems with > overscan (this I have confirmed, using Deluxe Paint III) because it does > not take the bus. Taking the bus is not what causes overscan problems. The problem with deep bitplanes and overscan is that the number of cycle on the chip bus available to ANY bus master, DMA device and 68000 alike, is reduced. The main reason the GVP works better in such situations than something like the A2090 is a detail of their buffering mechanisms, not the fact that one is non-DMA and the other is DMA. The GVP will go and get a whole block and save that in it's RAM before transferring, or something very similar. The A2090 doesn't have a large RAM, but in fact a FIFO that's less than a disk block long. So when transferring a block, if the A2090 can't get bus access and dump it's FIFO, the next chunk being transferred can be missed, and the cycle may have to be retried. It's actually possible to build a controller with a small FIFO that wouldn't have this problem if it knows how to wait state the SCSI transfer, which is apparently possible but not handled by the A2090. > He did say that the diskperf program is good to check out newer versions > of the driver software on the same drive. This is a accurate test to > tell if a new driver improves performance, no matter how bogus the number > is. I'm no expert on disk benchmarks, but was under the impression that the diskperf benchmark is pretty well accepted. It's true that any benchmark is good for testing relative speed of the same exact hardware under the slightly differing circumstances. For the same reason, I use the Dhrystone benchmark to tell me when my 68020 boards go faster. And while testing that same Dhrystone on another machine may not tell me the whole picture, it does give me some valid indiciation of the performance differences. And while the difference in Dhrystone between a Mac II and and Amiga 68020 machine don't tell me everything about those systems, it's a decent appraisal of the speed I'll get from small, integer-based programs on each of those system. Looking at the same benchmark run on a '386 system will tell me less, but it's still an indicator. Once I run the same benchmark on two Amiga systems with slightly different 68020 boards, I have a pretty specific indication of the relative integer performance of each board; there's nothing else to change. That doesn't necessarily tell me how total system performance will be (maybe one board has 32 bit RAM with DMA, and the other doesn't), or how a 500k program will necessarily compare (maybe one board has a much slower CPU with larger cache). Similarly, a program like diskperf run on two different hard disk systems is an indicator. If you make both systems Amigas, it's a better indication. If you use the same hard drive in both tests, you're now down to looking at the isolated performance of each disk-driver combination. If you just run diskperf, you're getting a good indicator of maximum possible speed. If you run diskperf along with several other programs, or multiple bitplanes, you'll get a different indication of performance. But with hardware matched that closely, I think it'll be a very good test. > -mark= -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
dwi@manta.NOSC.MIL (Steve Stamper) (04/21/89)
For what it is worth I get a diskperf figure of 655k/sec using a HardFrame controller/ Quantum Q80s drive and A2620 equipped 2000. I think I got about 560k/sec before the A2620 using the same drive/controller combo. -Roger Uzun
sneakers@heimat.UUCP (Dan "Sneakers" Schein) (04/22/89)
In Message <762@manta.NOSC.MIL>, dwi@manta.NOSC.MIL (Steve Stamper) writes: >For what it is worth I get a diskperf figure of 655k/sec using >a HardFrame controller/ Quantum Q80s drive and A2620 equipped 2000. >I think I got about 560k/sec before the A2620 using the same >drive/controller combo. Hmmm guess its time to throw in the speeds of heimat, here goes.... Keep in mind these times are not so much for comparing machine against machine (or set up against set up) but rather to show the difference between the stock 68000, a (CBM) 68020, and a 68020 using SetCPU V1.5 and its "FastROM" option. Hardware is the CBM 2090A conteoller and a Control Data 40meg 5.25" half height ST-506 drive. AmigaDOS V1.3 using the Fast Filing System. The cpu set up is listed before each set of results. [ 68000 ] DiskPreformance - V3.0 - 03/21/89 Testing drive ffs2: with big files (harddisk mode) File create/delete: create 15 files/sec, delete 45 files/sec Directory scan: 92 entries/sec Seek/read test: 91 seek/reads per second r/w speed: buf 1024 bytes, rd 51067 byte/sec, wr 48545 byte/sec r/w speed: buf 8192 bytes, rd 172842 byte/sec, wr 140434 byte/sec r/w speed: buf 32768 bytes, rd 224694 byte/sec, wr 163840 byte/sec [ 68020 ] DiskPreformance - V3.0 - 03/21/89 Testing drive ffs2: with big files (harddisk mode) File create/delete: create 18 files/sec, delete 50 files/sec Directory scan: 156 entries/sec Seek/read test: 105 seek/reads per second r/w speed: buf 1024 bytes, rd 52167 byte/sec, wr 49932 byte/sec r/w speed: buf 8192 bytes, rd 173797 byte/sec, wr 149086 byte/sec r/w speed: buf 32768 bytes, rd 209715 byte/sec, wr 166440 byte/sec [ 68020 w/FASTROM ] DiskPreformance - V3.0 - 03/21/89 Testing drive ffs2: with big files (harddisk mode) File create/delete: create 19 files/sec, delete 50 files/sec Directory scan: 238 entries/sec Seek/read test: 133 seek/reads per second r/w speed: buf 1024 bytes, rd 52167 byte/sec, wr 49774 byte/sec r/w speed: buf 8192 bytes, rd 174762 byte/sec, wr 151967 byte/sec r/w speed: buf 32768 bytes, rd 224694 byte/sec, wr 181833 byte/sec Sneakers -- ___ Dan "Sneakers" Schein //// BERKS AMIGA BBS Sneakers Computing //// 80+ Megs of software & messages 2455 McKinley Ave. ___ //// 12/2400 Baud - 24 Hrs West Lawn, PA 19609 \\\\ //// 215/678-7691 \\\\//// {pyramid|rutgers|uunet}!cbmvax!heimat!sneakers
dwi@manta.NOSC.MIL (Steve Stamper) (04/23/89)
The exact Dispkerf Figures one can expect using the HardFrame DMA controller and the Quantum Q80s are as follows: w/ Stock B2000 (7.14 Mhz 68000) buffer 512 bytes rd 109226 wrt 28807 buffer 4096 bytes rd 262144 wrt 163840 buffer 8192 bytes rd 327680 wrt 238312 buffer 32768 bytes rd 524288 wrt 291271 w/ A2620 Amiga 2000 buffer 512 bytes rd 124830 wrt 29454 buffer 4096 bytes rd 291271 wrt 163840 buffer 8192 bytes rd 327680 wrt 238312 buffer 32768 bytes rd 655360 wrt 291271 All figures are in Bytes/sec. -Roger Uzun