From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: Compact Flash performance... Date: Thu, 31 May 2007 18:40:16 -0400 Message-ID: <465F4ED0.10508@rtr.ca> References: <6278d2220705301510y2d81f69eu38fb778d32de05e1@mail.gmail.com> <465E3FF0.9010709@rtr.ca> <6278d2220705310222rde9ad28ndfd8feced84a3c6f@mail.gmail.com> <465EBE20.6090803@rtr.ca> <6278d2220705311025q6ee030e2kd44b7302a50ac902@mail.gmail.com> <465F360D.6020603@rtr.ca> <6278d2220705311439x40f7b1c1l7cef54acd2e8fcea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from rtr.ca ([64.26.128.89]:4762 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752942AbXEaWkT (ORCPT ); Thu, 31 May 2007 18:40:19 -0400 In-Reply-To: <6278d2220705311439x40f7b1c1l7cef54acd2e8fcea@mail.gmail.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Daniel J Blueman Cc: bzolnier@gmail.com, linux-ide@vger.kernel.org, Linux Kernel , Alan Cox , Jeff Garzik Daniel J Blueman wrote: > On 31/05/07, Mark Lord wrote: >> Daniel J Blueman wrote: ... >> I don't know too much about the specifics, though, but perhaps the >> card is only capable of full speed in PIO6, which requires special >> cabling >> and is currently unsupported in libata (?). > > Seems less likely, as the Extreme IV reader (and another) supports > UDMA mode 4; in PIO mode 6, they apparently top out at 17MB/s [2], > which seems reasonable. That's pio4 (16.6666MBytes/sec). pio6 should have the same cycle time as udma4. >> Another factor, is that hdparm performs discrete, non-overlapping, >> reads of 1MByte chunks for its timing test. Some drives cannot achieve >> full performance with such (relatively) large gaps between IO's. > > 100MB transfers still achieve 32MB/s: But internally libata is probably breaking those up into 64KB transfers, with gaps between requests. The best it could do would be 128KB transfers. To maximize throughput, some kind of host-queuing would be needed, or just have the driver sit in a tight loop, starting the next I/O immediately when the previous one finishes. Linux isn't that quick (yet). Cheers