Re: [PATCH] speed up SATA

["Eric D. Mudama" <edmudama@mail.bounceswoosh.org>]

On Sun, Mar 28 at 12:54, Jeff Garzik wrote:
>Jamie Lokier wrote:
>>This is what I mean: turn off write cacheing, and performance on PATA
>>drops because of the serialisation and lost inter-command time.
>>
>>With TCQ-on-write, you can turn off write cacheing and in theory
>>performance doesn't have to drop, is that right?
>
>hmmm, that's a good point.  I honestly don't know.  Something to be 
>tested, I suppose...
>
>My premature guess would be that you would need a queue depth larger 
>than 2 or 4 before performance starts to not-suck.

Write-cache off + queueing means that the drive can't "finish" the
command until it is on the media.  This means that until the block is
written, you won't get a 0x50 status or a SetBits FIS.

In theory, write-cache-off queueing will be slightly slower than
random reads+queueing, since most drives have slightly stricter
guidelines for write-settle versus read-settle.  (read settle you can
let your ECC hardware tell you that you pooched a seek and went
offtrack because you were still vibrating, for writes that is liable
to corrupt good data on adjacent tracks which you may not have in
buffer and therefore might not be able to repair.)

However, cached writes (queued or unqueued), especially small ones,
will have WAY higher ops/sec.  ATA TCQ is limited to 32 choices for
the next best operation, but an 8MB buffer doing 4K random-ops could
potentially have ~2000 choices for the next thing to do. (assuming
perfect cache granularity, etc, etc)

At 32 choices, the seek and rotate are still somewhat significant,
though way better than unqueued.  With 2000 things to choose from, the
drive is never, ever idle.  Seek, land just-in-time, read/write,
rinse/repeat.

--eric


-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org