Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!destroyer!ncar!csn!raven!rcd From: rcd@raven.eklektix.com (Dick Dunn) Subject: Re: DMA disk controllers Message-ID: <1992Oct27.185316@eklektix.com> Organization: eklektix - Boulder, Colorado References: <1992Oct26.062909@eklektix.com> <720149795snx@grendel.demon.co.uk> Date: Tue, 27 Oct 1992 18:53:16 GMT Lines: 55 jes@grendel.demon.co.uk (Jim Segrave) writes: >[I wrote] >> There are two buses to consider: I/O and memory. DMA can't take over the >> memory bus, because it can only feed it via the I/O bus, which is much >> slower. Therefore, the CPU can sit and crank in memory while data dribbles >> in/out. >ISA machines do both memory and I/O down the same bus. I hate to do one of these "is so!"--"is not!" exchanges, but this is just plain wrong. We *are* talking about 386 machines, right? 386 ISA-bus machines are built with an I/O bus, which is the good ol' 16-bit-wide 24-bit-address "AT bus" AND a separate interconnection between the CPU and memory. This separate interconnect will be 32 bits wide (except for 386SX systems), will be much faster, and these days will commonly have more than 24 address bits. There are two separate buses. [ObHistory: 286 ATs are generally built to have memory and peripherals on the same bus, the ISA bus. There were a few early 386 designs that worked that way, mostly as quick interim solutions to get 386 machines out. I don't know of any such machines built within the last four years. It should be obvious that you don't feed a 32 bit CPU with a cycle time from 67 down to 20 ns via a bus that can only deliver 16 bits every 375 ns!] 70 ns ( >> I'm not convinced the 8237 can drive the I/O bus to capacity, either. I >> believe that even when it's running flat-out, and even after taking bus >> arbitration into account, there are still I/O bus cycles available... .... >No, when a DMA controller is in burst mode (which would be the mode used >for disc and network controllers where the data to be moved resides in >or is going to a memory buffer on the controller), the bus is completely >seized by the DMA controller for the duration of the transfer. There are >no CPU cyles left. I know how burst-mode DMA works. But I'm not talking about any old DMA controller and bus. I'm talking about the 8237 (well, OK, the 8237A-5 [fast version] or equivalent) on the ISA bus. The claim is that the 8237 can transfer 1.6 MB/sec. The ISA bus is capable of 5.3 MB/sec. THAT is why I think there should be bus cycles left over. If you're claiming that the overhead takes the other 70% (!) of bus bandwidth, it would be nice to see a sketch of timing to prove it. (I could believe it...I've seen stranger things...but I won't accept it on faith.) >> And, as someone else already mentioned, you may be able to reduce interrupt >> overhead using DMA. .... >...the reduction in interrupts will be by page >size/sector size - about an 8 to 1 reduction. This will produce a slight >performance edge, but nothing very significant. Excuse me? An 8:1 reduction in interrupts isn't significant??? I can't fathom a reason for this statement. -- Dick Dunn rcd@raven.eklektix.com -or- raven!rcd Boulder, Colorado ...Simpler is better.