Subject: Re: CompactFLash performance improvement
To: Artem Belevich <art@riverstonenet.com>
From: Ian Zagorskih <ianzag@megasignal.com>
List: tech-kern
Date: 02/28/2004 18:01:28
On Saturday 28 February 2004 07:10, Artem Belevich wrote:
Just one notice - the same is absolutely true too for Disk On Module (DOM)
flash IDE compatible cards. Upon system query they claim to be only PIO mode
0 compatible -> incredible [inacceptable] speed slow down. At the same time
on the same hardware i can achieve up to 1..2 Mb/s transfer under Windows
system.
AFAIU the problem is that card itself dosn't return the actuall information
about its ATA capabilities [btw up to ATA-3] so kernel get's the lowest ATA
level. AFAIK there's no way to force the card (CF or DOM) to return the real
info :( Maybe manual quirks in kernel would help but i didn't find anything
like this.
Any ideas ?
> Some time back I've whined about painfully slow I/O on CompactFlash
> cards in IDE mode. Looks like it could be improved.
>
> To recap, under NetBSD/FreeBSD compactflash operations are several
> times slower than they are under Windows or Linux.
>
> Recently I've spent some time tracking the problem and it looks like
> with some driver changes it would be possible to speed it up.
>
> The issue is that:
> a) most CompactFlash cards claim to be capable of 1-sector PIO0
> transfers only. I think it was a requirement in the CF+ spec before
> rev1.4.
> b) CF cards have fairly long command-to-DRQ delay. One of Sandisk CF
> datasheets says that it can be up to ~1.2ms. My measurements show the
> number pretty close to that.
> c) NetBSD driver issues a read command for *every* sector.
>
> Here's a timeline for reading a single sector during 'dd bs=8192 count=<a
> lot>'.
>
> 0 issue read command with sector count=1
> +~1300us interrupt happens (first command takes long)
> +~ 250us fetch the data from the disk
>
> while(have sectors to read){
> 0 issue read command with sector count=1
> +~300us interrupt happens
> +~250us fetch the data from the disk
>
> + 20us issue next command
> }
>
> All in all it's ~570us/sector or <1Mb/s.
>
> I've experimented a bit with ATA drivers I've got from
> http://www.ata-atapi.com/drvr.htm and with the same CF card I'm able
> to achieve ~3.3Mb/s read rate compared to ~900K/s I've got from the
> same card with NetBSD.
>
> The main difference between ata-atapi.com's code and NetBSD is that
> NetBSD issues read command with 1-sector count and ata-atapi.com's
> driver reads several sectors at a time (32 in my case).
>
> The timings in this case looks like this:
>
> 0 issue read command with sector count=N
> +~1300us interrupt happens (first command takes long)
> +~ 250us fetch the data from the disk
>
> while (more sectors) {
> wait for next interrupt
> + 11us interrupt happens (*** only 11us until CF delivers next sector.
> + 250us fetch data
> }
>
> In this case it's ~260us/sector or ~2Mb/s.
>
> So, if we could change NetBSD driver to issue single read command for
> N secors at a time, we'd be able to speed-up CF I/O quite a bit.
>
> Note that I'm talking about regular read/write commans (0x20/0x30),
> not read-multiple/write-multiple commands (0xc4/0xc5). I
>
> Now, I'm not an expert on ATA/IDE and I'd appreciate if someone more
> familiar with the subject could take a look at the issue at see if and
> how it can be dealt with.
>
> I wonder if the issue merits opening a PR for it.
>
> --Artem
>
// wbr