Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!darwin.sura.net!news-feed-2.peachnet.edu!umn.edu!csus.edu!netcom.com!adler From: adler@netcom.com (Bruce Adler) Subject: Re: More annoyance on the DMA problem Message-ID: <adlerCBpvpJ.K5v@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <jmonroyCBoq14.Kz0@netcom.com> <jmonroyCBp5Ks.CM3@netcom.com> Date: Fri, 13 Aug 1993 21:29:42 GMT Lines: 30 In article <jmonroyCBp5Ks.CM3@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: > OK...32 sectors per second. > > 66,287 / 32 = 2071 refreshes per sector transfer. > > 1 / 32 = 0.03125 second per sector transfer > > Gee! Thanks for the correction. > > This makes the new index 5. The numbers match exactly. > > MY POINT IS THE LOWER HARMONIC OF THE DMA REFRESH > COLLIDES WITH THE FDC TRANSFER. That's utter nonsense! Do you use the same numerology to choose your lottery numbers? On a 4MHz PC, a refresh takes 5 clock cycles. Which means the DMA request will be delayed at most 1.25 microseconds. Of course, all real PCs are faster than 4MHz, but let's assume 4MHz to prove my point. The 1.25 microsecs is substantially less than the 13 microsecond maximum inter-byte delay specified by the 8272A FDC for the 500kb/s data rate. On a real machine you might see a 400 nanosecond refresh delay. So how can a SUB-MICROSECOND delay in servicing a DMA request cause an overrun? I've NEVER seen any (working) device driver for the PC that was caused to fail by a DRAM refresh cycle. I've worked on at least five different unix floppy drivers. None of them ever failed due to a refresh cycle.