From owner-freebsd-hackers  Tue Jun  3 09:26:59 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA07336
          for hackers-outgoing; Tue, 3 Jun 1997 09:26:59 -0700 (PDT)
Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA07329
          for <hackers@freebsd.org>; Tue, 3 Jun 1997 09:26:54 -0700 (PDT)
Received: from x14.mi.uni-koeln.de (annexr2-47.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA03862
  (5.67b/IDA-1.5 for <hackers@freebsd.org>); Tue, 3 Jun 1997 18:26:33 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id SAA21588; Tue, 3 Jun 1997 18:26:16 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
 yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
 EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-Id: <19970603182533.49926@mi.uni-koeln.de>
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 ?
References: <199706031041.MAA25969@labinfo.iet.unipi.it> <199706031502.JAA04331@pluto.plutotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <199706031502.JAA04331@pluto.plutotech.com>; from Justin T. Gibbs on Tue, Jun 03, 1997 at 09:58:58AM -0600
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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