linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: bzolnier@gmail.com, linux-ide@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeff Garzik <jeff@garzik.org>
Subject: Re: Compact Flash performance...
Date: Thu, 31 May 2007 18:33:50 -0400	[thread overview]
Message-ID: <465F4D4E.6050305@rtr.ca> (raw)
In-Reply-To: <6278d2220705311439x40f7b1c1l7cef54acd2e8fcea@mail.gmail.com>

Daniel J Blueman wrote:
> On 31/05/07, Mark Lord <liml@rtr.ca> wrote:
>> Daniel J Blueman wrote:
>> > Whoops, yes. Here is the expected data:
> [snip]
>>
>> Thanks.  I'll use that data to update/validate future versions of hdparm.
>> At UDMA66, it *should* be capable of the 40MByte/sec realm of readback 
>> perf,
>> assuming the card itself is really that fast.
> 
> hdparm in the other identify mode does list the UDMA3/4 modes twice
> [1], which looks odd.
> 
>> 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.
> 
>> 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:
> 
> # dd if=/dev/sdb of=/dev/null bs=100000k count=10
> 10+0 records in
> 10+0 records out
> 1024000000 bytes (1.0 GB) copied, 31.9328 seconds, 32.1 MB/s
> 
>> Also, just for fun, you could try "hdparm --direct -t /dev/sdb"
> 
> # hdparm --direct -t /dev/sdb
> 
> /dev/sdb:
> Timing O_DIRECT disk reads:   96 MB in  3.05 seconds =  31.47 MB/sec
> 
> It is conceivable that the controller in the two particular readers
> which get 40MB/s are doing some kind of prefetching, but seems seems
> like an extreme gain.

Okay, here's the new hdparm information for this:

Capabilities:
	...
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:
        Enabled Supported:
                Write cache
           *    CFA feature set
           *    CFA advanced modes: pio5 *pio6

So, udma4 and pio6 are the fastest supported speeds.
According to the CFA specifications (v4.1), either of those modes
requires SHORT cables and special handling.   You probably have
regular (16-18") cables, and libata doesn't support PIO6,
and the motherboard chipset may not support the "special handling"
requirements in other ways.  Also, only one device on the cable.

I see from your earlier posting that libata selected UDMA/66 (udma4)
for the device though, since libata doesn't know that your cable
is too long.  And that mode is working, so that's probably as good
as it gets on that particular motherboard chipset.

Some cards may perform better when their "memory" interface is used
instead of the "I/O" interface, or vice-versa.  I'm not sure which
of the two methods was selected by libata (probably the "memory" interface).

There is also a "PC-Card" style interface with shared-memory,
which some USB readers *may* use as an alternative to the standard
IDE/ATA style interface.

Cheers

  reply	other threads:[~2007-05-31 22:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30 22:10 Compact Flash performance Daniel J Blueman
2007-05-30 22:31 ` Lee Revell
2007-05-31  9:18   ` Daniel J Blueman
2007-05-30 22:56 ` Bartlomiej Zolnierkiewicz
2007-05-31  3:24 ` Mark Lord
2007-05-31  9:22   ` Daniel J Blueman
2007-05-31 12:22     ` Mark Lord
2007-05-31 17:25       ` Daniel J Blueman
2007-05-31 20:54         ` Mark Lord
2007-05-31 21:39           ` Daniel J Blueman
2007-05-31 22:33             ` Mark Lord [this message]
2007-05-31 22:35               ` Mark Lord
2007-05-31 22:37               ` Jeff Garzik
2007-05-31 22:43                 ` Mark Lord
2007-06-02  5:10                   ` Willy Tarreau
2007-05-31 23:47               ` Daniel J Blueman
2007-05-31 22:40             ` Mark Lord
2007-05-31 23:26               ` Jeff Garzik
     [not found] <fa.XmtWMJk5gwBC00HJh+5O62Vx8eA@ifi.uio.no>
     [not found] ` <fa.fl4+oXGwE5VC39h2DLdFoBUbqV4@ifi.uio.no>
     [not found]   ` <fa.+cW0LouEqSiZ6zrmBDeBJxRjPTg@ifi.uio.no>
     [not found]     ` <fa.PM7erd/Gm1gq8ZshwTBJwux7o6o@ifi.uio.no>
     [not found]       ` <fa.MYVClL+Q9g/jFTcUNWOeysiV0Ig@ifi.uio.no>
     [not found]         ` <fa.Q4zXu+xtMAT5H5vbl/zgxZk/Ivo@ifi.uio.no>
2007-06-01  0:00           ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465F4D4E.6050305@rtr.ca \
    --to=liml@rtr.ca \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bzolnier@gmail.com \
    --cc=daniel.blueman@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).