Subject: Re: CompactFLash performance improvement
To: Artem Belevich <art@riverstonenet.com>
From: Ferry Sutanto <fsutanto@yahoo.com>
List: tech-kern
Date: 02/27/2004 18:54:26
--- Artem Belevich <art@riverstonenet.com> wrote:
> Do you have a diff for your changes?  
> I've tried to do something like this, but driver
> seemed to idnore all
> but the first sector in the transfer.

It has been a while, but I will post a diff.

PS: I have never post a diff for any improvement I did
on NetBSD, and I know that I should RTFM, but few
pointers will be helpful :)

Thanks!

Ferry


> 
> --Artem
> 
> On Fri, Feb 27, 2004 at 05:51:43PM -0800, Ferry
> Sutanto <fsutanto@yahoo.com> wrote:
> > Hi,
> > 
> > I made some changes to the ATA driver runs on
> SanDisk
> > compact flash. SanDisk claim that it can
> read/write
> > multiple sectors with single sector read/write
> > command. In other words, the driver still issue
> single
> > sector read/write command, but I set 'n' sectors
> in
> > sector count register. I try it and it has been
> > working wonderfully for 2 years now.
> > 
> > Thanks!
> > 
> > Ferry
> > 
> > --- Artem Belevich <art@riverstonenet.com> wrote:
> > > 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
> > > 
> > > On Sun, Jul 14, 2002 at 07:26:00AM +0200,
> Wojciech
> > > Puchar <wojtek@chylonia.3miasto.net> wrote:
> > > > > Not the one(s) I have.
> > > > >
> > > > > wd1 at wdc0 channel 0 drive 0: <Hitachi
> > > CVM1.3.3>
> > > > > wd1: drive supports 1-sector PIO transfers,
> LBA
> > > addressing
> > > > > wd1: 244 MB, 695 cyl, 15 head, 48 sec, 512
> > > bytes/sect x 500400 sectors
> > > > >
> > > > > So far all the CompactFlash cards I saw
> > > (sandisk/lexar/io data/several
> > > > > no-names) reported themselves as PIO 0 with
> > > 1-sector-at-atime transfer
> > > > > capability. :-( I believe, that's what one
> of
> > > the earlier CF specs
> > > > > insisted upon.
> > > > >
> > > > > I saw some references to the
> multisector-capable
> > > CF cards on the web,
> > > > > but I haven't seen any of them myself yet.
> > > > 
> > > > i think it's possible they really can
> multisector
> > > but don't report. and
> > > > with >1sec/s will be same 3000us delay
> > > > 
> > > > 
> > > > >
> > > > > --Artem
> > > > >
> > > > > On Sat, Jul 13, 2002 at 08:27:23AM +0200,
> > > Wojciech Puchar <wojtek@chylonia.3miasto.net>
> wrote:
> > > > > > > snapshot for both windows and NetBSD.
> This
> > > should at least give us a
> > > > > > > hint why are we so slow.
> > > > > > >
> > > > > > > What I see is that single-sector read
> > > consists of
> > > > > > >
> > > > > > > 	command + 275us wait time + 150us data
> > > transfer time = 430us.
> > > > > > >
> > > > > > > Write, on the other hand, looks a bit
> > > different:
> > > > > > > 	command+150us data transfer+2850us wait
> 
=== message truncated ===

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools