linux-kernel - Re: Compact Flash performance...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6278d2220705311647l48dfcfdbkb826826e11dccef4@mail.gmail.com>
Date:	Fri, 1 Jun 2007 00:47:14 +0100
From:	"Daniel J Blueman" <daniel.blueman@...il.com>
To:	"Mark Lord" <liml@....ca>
Cc:	bzolnier@...il.com, linux-ide@...r.kernel.org,
	"Linux Kernel" <linux-kernel@...r.kernel.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Jeff Garzik" <jeff@...zik.org>
Subject: Re: Compact Flash performance...

Hi Mark,

On 31/05/07, Mark Lord <liml@....ca> wrote:
> Daniel J Blueman wrote:
> > On 31/05/07, Mark Lord <liml@....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:
>
[snip]
>            *    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.

It makes sense for Linux to default to normal cable lengths in absence
of some mechanism to detect or specify this; in this case my CF card
is plugged directly into the motherboard with a CF adapter [1], so one
device, short traces. Anyway, I'd imagine the "special handling" and
other requirements have been introduced/influenced by vendors, so
possibly more special-cased than possible here.

> 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.

I couldn't find a kernel parameter to specify if I have a long/short
cable. Is there a way?

> 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

Thanks for the detail in the other mails too; it's useful,
  Daniel

--- [1]

http://img.inkfrog.com/pix/kitty.wun/Female_CF_type3.jpg
-- 
Daniel J Blueman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/