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