Date: Tue, 3 Jun 1997 18:25:33 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, "John S. Dyson" <toor@dyson.iquest.net>, hackers@FreeBSD.ORG Subject: Re: DMA for IDE drives ? Message-ID: <19970603182533.49926@mi.uni-koeln.de> In-Reply-To: <199706031502.JAA04331@pluto.plutotech.com>; from Justin T. Gibbs on Tue, Jun 03, 1997 at 09:58:58AM -0600 References: <199706031041.MAA25969@labinfo.iet.unipi.it> <199706031502.JAA04331@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 3, "Justin T. Gibbs" <gibbs@plutotech.com> wrote: > Do the newer IDE drives support any concept similar to tagged queueing? > Perhaps via EATA? Supporting DMA is only half the battle in my mind as you > won't get anywhere near the throughput of a SCSI drive if you can't > schedule and have the drive reorder multiple transactions at a time. No, and there is also limited parallelism supported with regard to the two drives that share one EIDE port. You can't overlap data transfers of those drives, i.e. after you start reading on the first one, you have to accept all the data requested before you can issue a command to the second drive. That can add quite some command latency. Even if, say, 64KB of data are already in the drive's cache, the transfer will take 4ms at 16MB/s ... (this will be cut in two if you use 33MB/s "Ultra-EIDE", but there are hardly any motherboards nor drives installed, that can take advantage of this. (And BTW: The command overhead of a VERY fast EIDE drive (Maxtor DiamondPro) is specified as 0.5 milli-seconds, and this time has to be added to the 4ms for the transfer, above, to calculate the maximum effective latency for accesses to a second drive on the same EIDE port). Hope I got all that right. But you'll surely let me know, if I didn't ... :) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970603182533.49926>