Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.unix.amiga Subject: Re: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long) Keywords: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, etc. Message-ID: <20285@cbmvax.commodore.com> Date: 2 Apr 91 17:20:24 GMT References: <19986@cbmvax.commodore.com> <1991Mar20.100122.1717@kessner.denver.co.us> <20030@cbmvax.commodore.com> <1991Mar22.053324.8867@kessner.denver.co.us> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 106 In article <1991Mar22.053324.8867@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <20030@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >Hmmm. On the original AT, it was found that using a busy loop rather than >DMA was faster (although I forgot the exact reason for this). The reason is you're not talking about real DMA here. Read on... >To the best of my knoledge, all controllers have the ability to do DMA >transfers, but the controller BIOS has ultamate say as to which method is >used. Only the high end of PC bus controllers, usually SCSI things on a EISA or MCA bus, do real DMA. What you're thinking of is "DMA" using the standard PC DMA controller rather than the CPU. This DMA controller was faster than a busy PIO loop on an 8088 machine. Not because it ran bus cycles any faster; it didn't. But it pretty much eliminated the overhead of the PIO loop, since it could read from the disk controller, dump to memory, and loop, all without fetching instructions. Once you got to PC-AT level, the 80286 chip could do the PIO move faster than the DMA controller, so most '286 and '386 systems do just that. Neither is an acceptible method in a real multitasking OS. >and the developers of UNIX on a 386 may have done just that-- thinking that >DMA on a multi-tasking system is better... I doubt it. Using the DMA controller would still tie up the bus just as much as the '386 would, doing the move. The DMA controllers still run real slow. The way they address memory beyond 1MB, as I recall, is a kludge (or at least was in the original PC-AT implementation). No matter what, you still end up with two bus crossings, wait states, and no buffering. Most '386 systems use disk interfaces that, like the '386, probably go faster than the DMA controller. While I don't know what the UNIX folks do either, other than maybe pray you have a real DMA (eg, bus mastering) hard disk controller with FIFO or cache, I doubt they use the DMA controller, it is archaic. >If disk speed becomes a problem, you could always add four meg of RAM and >increase the disk cache/buffers (you can get away with this on a cheap >system). That'll help performance on a system with a low performance non-DMA controller. It may actually hurt performance on a system like the A3000, though it's not obvious to everyone. Certainly a little bit of intelligent caching helps by eliminating extra seeks, on any system. But, as long as you have a DMA driven hard disk controller that runs bus cycles as fast as the host CPU (as on the A3000), a transfer from the hard disk controller is twice as fast as a CPU cache hit, ignoring cache detection time (which would increase the difference). >You could also go for a cached controller board (that has UNIX drivers). That's exactly what you want in the above fast DMA controller senario. With a slower hard disk interface, the host system needs to do the caching. The A3000 sits somewhere in the middle, caching can help out on the hard disk and to some extent in the host filesystem. >There is another issue here... The BEST CASE 030/25 machine I have seen (of >any brand) gets no more than 9000 dhrystones/sec. I came up with this >figure by looking at EVERY figure given to me via mail or magazines. Most >were in the high 7000's, but there were several (30%) in the 8500 range. >giving the 030 the benifit of a doubt I'll say the best case was 9000. I did >thow out one figure of an 030/25 doing approx 12,000 because it was only one >in a list of about 60 figures. You shouldn't do that. That was an HP '030 workstation, the only one in the list, I'll wager, with an external cache. Many '030 systems: Mac IIs (except IIfx), Amigas, NeXT, some of the cheaper workstations in the Sony, Suns, and Apollo lines, have no external cache. Cache isn't the only architectural issue, either. Some of the old Sun video displays, for example, steal lots of time from the main memory bus. VGA isn't fast, but it doesn't intrude on purely CPU intensive benchmarks, either. >Keep in mind that there were for 030/25's in general rather than just the >A3000-- so most were cached... Don't count on it. >On the other side, none of the 386/25 (cached or not) figures I have seen (via >the same method/sources as the 030/25's) were under 10,500. It was closer to >11,500 for cached systems. This is all assuming that the 386 benchmark was not >running under MS-DOG, where the speed would be HALF that. Actually, the fastest benchmarks you can get on a PC Clone are under MS-DOS with a DOS extender, where you run 32 bits wide but the benchmark has complete ownership of the system. >Hmmm. Can someone tell me what the latest news from CeBit is? I guess I >missed that one... A3000T. See the new AmigaWorld... >It's comming back to me now... Ahh, drive music! On another topic here, >someone was telling me that the 3.5" drive for the C64 (the 1581?) has a >faster 6502 in it-- like 4mhz or something. Is this true? I sold my 64 >before it came out. If it is true, why? Better fidelity with drive music? It might be 2MHz, I'm not sure. Not 4MHz, real production quantities of 4MHz 6502 compatible chips didn't exist back then. Greg Berlin, the designer of the 1581, also designed the A2232 serial card (with 3.56MHz 6502 compatible) and worked with me on the A3000 (he designed the Gary and RAMSEY chips). >David Kessner - david@kessner.denver.co.us | do { -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.