Date: Thu, 23 Mar 1995 02:55:07 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, sos@login.dknet.dk Cc: faq@FreeBSD.org, hackers@FreeBSD.org, hasty@star-gate.com, phk@ref.tfs.com Subject: Re: Why IDE is bad Message-ID: <199503221655.CAA20070@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> >And that is the main thing on E-IDE, the drives are designed >> >> >with enough onboard cache, that coretest etc. reports transfer >> >> >rates close to the interface speed (13MB sec or so), but the >> >> >drive cannot hold this speed when it has to read from the media. >> >> >> >> This is also good for reducing interrupt overhead. >> >> >Hmm, most of the drives would intterupt once each sector anyway >> >even when doing DMA, so there is really nothing gained... >> >> Interrupts don't take long (< 10 usec on a DX2/66) if the driver >> doesn't do anything. The IDE driver does a lot. It takes at least >> 155 usec to transfer 512 bytes at 3.3MB/sec. Dividing `a lot' by >> (11.3/3.3) has good effects. >Hmm, yes but most motherboards can only run code off the cache >when the onboard DMA is running, limiting the usefullness of >this approach "somewhat". Besides the DOS dudes allready found out >and you will have VERY big trouble even finding a DOS DMA driver.... I meant (in the >> >> quote) that fast PIO is good for reducing total overhead. Most of the overhead happens to show up as `Intr' overhead because the insw/outsw is done in the interrupt handler. Reducing this from 155 usec to 39 usec is much more useful than reducing the interrupt entry overhead from 10 usec to 0. All this ignores the effects of caches. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503221655.CAA20070>