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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 31 May 2007 22:39:29 +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...

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.

I'll check things out with the IDE PIIX code also. Thanks for your help!
  Daniel

> Cheers

--- [1]

# hdparm -i /dev/sdb

/dev/sdb:

 Model=SanDisk SDCFX-4096                      , FwRev=HDX 4.04,
SerialNo=    116802D2807J3335
 Config={ HardSect NotMFM Removeable DTR>10Mbs nonMagnetic }
 RawCHS=7964/16/63, TrkSize=0, SectSize=576, ECCbytes=4
 BuffType=DualPort, BuffSize=1kB, MaxMultSect=4, MultSect=?0?
 CurCHS=7964/16/63, CurSects=8027712, LBA=yes, LBAsects=8027712
 IORDY=no, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma3 *udma4
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-4

 * signifies the current active mode

--- [2]

http://www.robgalbraith.com/bins/content_page.asp?cid=7-7896-8475
-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ