Hi Mark,
On 31/05/07, Mark Lord <liml@xxxxxx> wrote:
Daniel J Blueman wrote:
> On 31/05/07, Mark Lord <liml@xxxxxx> 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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
