Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13324 comp.os.linux.development:222 comp.os.mach:3191 comp.os.minix:22578 comp.periphs:4173 comp.unix.bsd:12458 comp.unix.pc-clone.32bit:4110 comp.os.386bsd.development:1110 Newsgroups: comp.os.os2.programmer,comp.os.linux.development,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!mcsun!sun4nl!relay.philips.nl!philica!adrie From: adrie@ica.philips.nl (Adrie Koolen) Subject: Re: More on the DMA timing problem Message-ID: <1993Aug19.070551.1336@ica.philips.nl> Organization: Philips Consumer Electronics, Eindhoven, The Netherlands References: <jmonroyCBopts.KM8@netcom.com> <1993Aug16.072355.292@ica.philips.nl> <adlerCBy8o4.I9v@netcom.com> Date: Thu, 19 Aug 1993 07:05:51 GMT Lines: 41 In article <adlerCBy8o4.I9v@netcom.com> adler@netcom.com (Bruce Adler) writes: >In article <1993Aug16.072355.292@ica.philips.nl> adrie@ica.philips.nl (Adrie Koolen) writes: >>When using 8 bits wide DMA in Single Transfer mode, each DMA transfer >>takes about 3 ms. 64 KB then takes 192 ms, which certainly is longer > ^^^^ ^^^^^^ >>than the refresh period, although most DRAMs will operate with refresh >>periods of 192 ms (though not guaranteed!). > >I assume in first instance you meant "ms" to be microseconds and in Oops, you're right. When asserting a DRQ, the 8237a takes around 1 us to acknowledge it (assert DACK). Then, in Single Transfer mode, it takes 8 AT-bus cycles to transfer one byte, i.e. 1 us on an 8 MHz AT-bus. And then there's a release time of again some 1 us (I've looked at it with an oscilloscope). This adds up to 3 us. >the second instance it means milliseconds. Regardless, your timing >numbers are way to high and conflict with your later estimate of >a max thruput of 5 MB/s. > >>When using Demand Transfer mode and 16 bits wide DMA, transfer speed >>maxes out at some 5 MB/s, so 64 KB would take some 13 ms. This is still > ^^^^^^ >>longer than the refresh period (4 or 8 ms, I believe). > >I always assume that a DMA /transfer takes four or five cycles (depending >whether it's a zero wait state device and/or how quickly your memory >controller recognizes the DMA request from the device). Therefore, on >a 10MHz bus that's about 500 nsecs per transfer, not 3 usecs. In Demand Transfer mode, you grab the bus (DRQ: 1 us), do a number of transfers (min 3 AT-bus cycles per 16-bits transfer), and release the bus (again 1 us). The burst transfer rate thus is 2*8/3 = 5.3 MB/s, though you'll never get that in real life. When holding the AT-bus too long, one might starve another DMA stream, like the FDC, who wants to read or write a byte every 16 us and will loose bytes if not serviced timely. Adrie Koolen (adrie@ica.philips.nl) Philips Consumer Electronics, Eindhoven, the Netherlands