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:40:16 -0400 [thread overview]
Message-ID: <465F4ED0.10508@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:
...
>> 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
next prev parent reply other threads:[~2007-05-31 22:40 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
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 [this message]
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=465F4ED0.10508@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).