How to test SATA NCQ feature

How to test SATA NCQ feature

[Fajun Chen]

Hi Folks,

I'm writing a program to test SATA Sil3124 NCQ feature.  I assume NCQ
is supported by libata by default, correct?  Multi threading approach
is used to send AT commands to device asynchronously.  I can verify
that data are sent to the device and read back correctly, but I don't
know how to verify if NCQ works.  Do I expect to see consistent
performance gain in random read/write in NCQ mode?

Thanks,
Fajun

Re: How to test SATA NCQ feature

[Eric D. Mudama]

For small random reads across the full stroke of the disk, you should
see 50-80% improvement in performance, regardless of the state of read
cache, at a depth of 32.

For small random writes across the full stroke, performance should be
unchanged if write cache is enabled in the drive.  If write cache is
disabled, you should see the same 50-80% performance improvement as
for random reads.

For sequential operations NCQ won't make much of a difference, and as
the command block size increases, the performance delta will shrink
between queued and non-queued.  The exact asymptote is a function of
many manufacturer and model-specific details.

Remember that these are all ops/sec measurements.  Command latency is
a different kettle of fish.

--eric


On 10/12/06, Fajun Chen <fajunchen@gmail.com> wrote:
> Hi Folks,
>
> I'm writing a program to test SATA Sil3124 NCQ feature.  I assume NCQ
> is supported by libata by default, correct?  Multi threading approach
> is used to send AT commands to device asynchronously.  I can verify
> that data are sent to the device and read back correctly, but I don't
> know how to verify if NCQ works.  Do I expect to see consistent
> performance gain in random read/write in NCQ mode?
>
> Thanks,
> Fajun
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: How to test SATA NCQ feature

[Fajun Chen]

Hi Eric,

Thanks for your detailed explanation.

In terms of ops/sec, I currently implemented it as the amout of data
transferred per seconds.  Please let me know if I need to implement it
differently.

I also have a question about NCQ error handling. Among all the
outstanding commands, if one command fails,  what will happen to the
rest of the commands? I understand that all the commands in the device
will be aborted by LOG PAGE 10h command, but how about the commands
enqueued but haven't been sent to the device?  In my particular
application, one thread is blocked for every outstanding command. So
depending on how libata handles outstanding commands,  it will have
significant implication to my user space application.

Thanks,
Fajun

On 10/12/06, Eric D. Mudama <edmudama@gmail.com> wrote:
> For small random reads across the full stroke of the disk, you should
> see 50-80% improvement in performance, regardless of the state of read
> cache, at a depth of 32.
>
> For small random writes across the full stroke, performance should be
> unchanged if write cache is enabled in the drive.  If write cache is
> disabled, you should see the same 50-80% performance improvement as
> for random reads.
>
> For sequential operations NCQ won't make much of a difference, and as
> the command block size increases, the performance delta will shrink
> between queued and non-queued.  The exact asymptote is a function of
> many manufacturer and model-specific details.
>
> Remember that these are all ops/sec measurements.  Command latency is
> a different kettle of fish.
>
> --eric
>
>
> On 10/12/06, Fajun Chen <fajunchen@gmail.com> wrote:
> > Hi Folks,
> >
> > I'm writing a program to test SATA Sil3124 NCQ feature.  I assume NCQ
> > is supported by libata by default, correct?  Multi threading approach
> > is used to send AT commands to device asynchronously.  I can verify
> > that data are sent to the device and read back correctly, but I don't
> > know how to verify if NCQ works.  Do I expect to see consistent
> > performance gain in random read/write in NCQ mode?
> >
> > Thanks,
> > Fajun
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>

Re: How to test SATA NCQ feature

[Eric D. Mudama]

On 10/12/06, Fajun Chen <fajunchen@gmail.com> wrote:
> Hi Eric,
>
> Thanks for your detailed explanation.
>
> In terms of ops/sec, I currently implemented it as the amout of data
> transferred per seconds.  Please let me know if I need to implement it
> differently.

Ops/sec and blocks/s can easily be translated.  Doesn't really matter
which metric you use.

> I also have a question about NCQ error handling. Among all the
> outstanding commands, if one command fails,  what will happen to the
> rest of the commands?

Per the specification, upon any error, all commands internal to the
device are aborted.  Now, there's optimizations to this behavior
(drives may have internally queued command completions that they can
let finish before they report the error) but they don't affect the
host in any meaningful way.

>                                     I understand that all the commands in the device
> will be aborted by LOG PAGE 10h command, but how about the commands
> enqueued but haven't been sent to the device?  In my particular
> application, one thread is blocked for every outstanding command. So
> depending on how libata handles outstanding commands,  it will have
> significant implication to my user space application.

If queued in hardware but not yet issued to the device, I am not sure
how those would be handled... probably up to each vendor's hardware
specification.  Don't really know beyond that as I haven't written an
HBA driver before.  My work has all been on the device side.

--eric

Re: How to test SATA NCQ feature

[Jens Axboe]

On Thu, Oct 12 2006, Fajun Chen wrote:
> will be aborted by LOG PAGE 10h command, but how about the commands
> enqueued but haven't been sent to the device?  In my particular

Requests not yet issued to the device, all reside in the io scheduler
queue. When the drive invalidates its hardware queue, those previously
active commands are put back in to the io scheduler queue and now reside
with those that were yet to be issued. Once device recovery is complete,
queueing at the device level resumes.

Does that answer your question? Neither libata nor the device has any
knowledge of commands queue but not sent to the device.

-- 
Jens Axboe

Re: How to test SATA NCQ feature

[Fajun Chen]

Thanks, Jens. This answered my question.

Fajun

On 10/13/06, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Thu, Oct 12 2006, Fajun Chen wrote:
> > will be aborted by LOG PAGE 10h command, but how about the commands
> > enqueued but haven't been sent to the device?  In my particular
>
> Requests not yet issued to the device, all reside in the io scheduler
> queue. When the drive invalidates its hardware queue, those previously
> active commands are put back in to the io scheduler queue and now reside
> with those that were yet to be issued. Once device recovery is complete,
> queueing at the device level resumes.
>
> Does that answer your question? Neither libata nor the device has any
> knowledge of commands queue but not sent to the device.
>
> --
> Jens Axboe
>
>