NCQ general question

NCQ general question

[Raz Ben-Jehuda(caro)]

i am thinking of buying a promise card sataII pcix.
they have two types, a card which support NCQ
and another that does not.
What is the bennifit of buying  a card with NCQ tagging ?

i would be thankfull for any answer .
thank you.
raz.

Re: NCQ general question

[Gentoopower]

Raz Ben-Jehuda(caro) wrote:
> i am thinking of buying a promise card sataII pcix.
> they have two types, a card which support NCQ
> and another that does not.
> What is the bennifit of buying  a card with NCQ tagging ?
>   
How about: http://en.wikipedia.org/wiki/Native_command_queueing
> i would be thankfull for any answer .
> thank you.
> raz.
> -
> 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
>
>
>   



	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: NCQ general question

[Mark Lord]

Gentoopower wrote:
> Raz Ben-Jehuda(caro) wrote:
>> i am thinking of buying a promise card sataII pcix.
>> they have two types, a card which support NCQ
>> and another that does not.
>> What is the bennifit of buying  a card with NCQ tagging ?
>>   
> How about: http://en.wikipedia.org/wiki/Native_command_queueing

Yuck.. what a lousy wiki entry.

NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
making the host-side (controller, operating-system) quite a bit
simpler than with NCQ.

Both use 32-deep queue depths, and neither of them are worth a
damn on Linux yet.  Except possibly in the libata ahci driver,
or vendor-provided drivers (open source, even) for some chipsets.

In theory, NCQ/TCQ can speed up a very busy fileserver that is
handling mostly tiny I/O requests.  Practically no measurable
benefit for single-user systems.

Cheers

Re: NCQ general question

[Jens Axboe]

On Wed, Mar 01 2006, Mark Lord wrote:
> Gentoopower wrote:
> >Raz Ben-Jehuda(caro) wrote:
> >>i am thinking of buying a promise card sataII pcix.
> >>they have two types, a card which support NCQ
> >>and another that does not.
> >>What is the bennifit of buying  a card with NCQ tagging ?
> >>  
> >How about: http://en.wikipedia.org/wiki/Native_command_queueing
> 
> Yuck.. what a lousy wiki entry.

Yeah, it's pretty bogus.

> NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
> making the host-side (controller, operating-system) quite a bit
> simpler than with NCQ.

Or in laymens terms - TCQ sucks and NCQ doesn't :-)
NCQ has many more advantages than TCQ, apart from both a more efficient
low level protocol and ease of implementation. TCQ basically just allows
the drive to do some reordering, it still serializes everything and
requires too many interrupts.

> Both use 32-deep queue depths, and neither of them are worth a
> damn on Linux yet.  Except possibly in the libata ahci driver,
> or vendor-provided drivers (open source, even) for some chipsets.

Eh strange statement, NCQ works just fine in Linux with the NCQ patch.
On AHCI only of course, as that is the only docu I had available.

> In theory, NCQ/TCQ can speed up a very busy fileserver that is
> handling mostly tiny I/O requests.  Practically no measurable
> benefit for single-user systems.

Even single user systems easily have more than on pending request, I'd
say results are very measurable for random 4kb io. In real life the
casual single user wont see much benefit, mainly because he doesn't do a
whole lot of io. I have seen over 30% benefit in "micro" io benchmarks,
though.

-- 
Jens Axboe

Re: NCQ general question

[Steve Byan]

On Mar 1, 2006, at 8:55 AM, Jens Axboe wrote:

> On Wed, Mar 01 2006, Mark Lord wrote:
>> NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
>> making the host-side (controller, operating-system) quite a bit
>> simpler than with NCQ.
>
> Or in laymens terms - TCQ sucks and NCQ doesn't :-)
> NCQ has many more advantages than TCQ, apart from both a more  
> efficient
> low level protocol and ease of implementation. TCQ basically just  
> allows
> the drive to do some reordering, it still serializes everything and
> requires too many interrupts.

The problem with TCQ is that the host can't disconnect on writes  
after sending the data to the drive but before receiving the status.  
The host can only disconnect between sending the command and moving  
the data. Consequently TCQ is useless for writes, which is where you  
really need it. It works OK for reads. TCQ was really invented as a  
way to allow CD-ROM drives to play nice on the same ATA bus as disks.

The reason you need write queuing is for data integrity reasons, not  
for performance. ATA disks effectively get command-queuing on writes  
even without TCQ and NCQ - they simply park the data in a volatile  
RAM cache, tell the host that the data is saved on persistent  
storage, and then asynchronously write the queued data to the  
physical media. The drive reorders those writes and will gather  
sequential writes.

However, note that all filesystems that make even a pretense of  
trying to maintain filesystem integrity after a power failure (note  
that the Windows NT implementation of FAT32 does not attempt to  
maintain filesystem integrity after a power failure) depend on  
knowing when data makes it to persistent storage, so they can order  
their writes correctly. ATA disk write caching breaks this guarantee.  
To restore filesystem integrity on a careful-write filesystem like  
most unix filesystems, you have to disable write-caching in the  
drive. This causes such a drastic loss of performance (you basically  
get only one sequential write per disk revolution), that you must  
then implement command-queuing to allow the drive to gather  
sequential writes to make the system usable.

As an alternative, if you have a journalling filesystem, you can  
leave the disk cache enabled but selectively write-through your  
metadata using force-unit-access (FUA).

Regards,
-Steve
-- 
Steve Byan <smb@egenera.com>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

Re: NCQ general question

[Jeff Garzik]

Steve Byan wrote:
> On Mar 1, 2006, at 8:55 AM, Jens Axboe wrote:
> The problem with TCQ is that the host can't disconnect on writes  after 
> sending the data to the drive but before receiving the status.  The host 
> can only disconnect between sending the command and moving  the data. 

That, but also:  The standard PCI IDE hardware interface prevents the 
device from selecting command $N's DMA data out of $M active write commands.

With reads, the device has more freedom to process the requests 
asynchronously.


> Consequently TCQ is useless for writes, which is where you  really need 

Agreed.


> it. It works OK for reads. TCQ was really invented as a  way to allow 
> CD-ROM drives to play nice on the same ATA bus as disks.

Disagree, you are probably thinking about bus disconnect associated with 
the overlapped command set?  AFAIK TCQ has -never- applied to ATAPI.


> The reason you need write queuing is for data integrity reasons, not  
> for performance. ATA disks effectively get command-queuing on writes  
> even without TCQ and NCQ - they simply park the data in a volatile  RAM 
> cache, tell the host that the data is saved on persistent  storage, and 
> then asynchronously write the queued data to the  physical media. The 
> drive reorders those writes and will gather  sequential writes.

Data integrity -and- performance.  Performance increases for all the 
standard reasons that an asynchronous pipeline increases performance 
over a synchronous one.

The write cache means that requests on the device can be processed 
asynchronously, but without NCQ there is still a synchronous bottleneck: 
  the device<->controller pipe.


> However, note that all filesystems that make even a pretense of  trying 
> to maintain filesystem integrity after a power failure (note  that the 
> Windows NT implementation of FAT32 does not attempt to  maintain 
> filesystem integrity after a power failure) depend on  knowing when data 
> makes it to persistent storage, so they can order  their writes 

True.


> correctly. ATA disk write caching breaks this guarantee.  To restore 
> filesystem integrity on a careful-write filesystem like  most unix 
> filesystems, you have to disable write-caching in the  drive. This 

False, as Linux has proven:  barriers can be implemented with 
flush-cache commands.

Disabling write cache is not your only choice, and using flush-cache 
gives you better performance than flat-out disabling the write cache.

	Jeff

Re: NCQ general question

[Steve Byan]

On Mar 3, 2006, at 5:19 PM, Jeff Garzik wrote:

> Steve Byan wrote:
>> it. It works OK for reads. TCQ was really invented as a  way to  
>> allow CD-ROM drives to play nice on the same ATA bus as disks.
>
> Disagree, you are probably thinking about bus disconnect associated  
> with the overlapped command set?

Yep, I had the two concepts confused. Thanks for the clarification.  
Isn't the same bus disconnect used for TCQ, though?

> Data integrity -and- performance.  Performance increases for all  
> the standard reasons that an asynchronous pipeline increases  
> performance over a synchronous one.
>
> The write cache means that requests on the device can be processed  
> asynchronously, but without NCQ there is still a synchronous  
> bottleneck:  the device<->controller pipe.

True, but I think that is fairly small compared to no-write-cache-and- 
no-queuing case. Write-caching is the major win; optimizing the data  
transfer is only a second-order effect.

>> correctly. ATA disk write caching breaks this guarantee.  To  
>> restore filesystem integrity on a careful-write filesystem like   
>> most unix filesystems, you have to disable write-caching in the   
>> drive. This
>
> False, as Linux has proven:  barriers can be implemented with flush- 
> cache commands.
>
> Disabling write cache is not your only choice, and using flush- 
> cache gives you better performance than flat-out disabling the  
> write cache.

Yes, you're correct; I neglected to include that option. It's not as  
good as real FUA because it flushes the entire cache, not just the  
metadata which needs to be written through to the media.

Regards,
-Steve
-- 
Steve Byan <smb@egenera.com>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

Re: NCQ general question

[Jeff Garzik]

Steve Byan wrote:
> 
> On Mar 3, 2006, at 5:19 PM, Jeff Garzik wrote:
> 
>> Steve Byan wrote:
>>
>>> it. It works OK for reads. TCQ was really invented as a  way to  
>>> allow CD-ROM drives to play nice on the same ATA bus as disks.
>>
>>
>> Disagree, you are probably thinking about bus disconnect associated  
>> with the overlapped command set?
> 
> 
> Yep, I had the two concepts confused. Thanks for the clarification.  
> Isn't the same bus disconnect used for TCQ, though?

Yes.  TCQ still has nothing to do with ATAPI though, which was the main 
point of disagreement :)  Much to my chagrin, too, since ATAPI could use 
some queueing...


>> Data integrity -and- performance.  Performance increases for all  the 
>> standard reasons that an asynchronous pipeline increases  performance 
>> over a synchronous one.
>>
>> The write cache means that requests on the device can be processed  
>> asynchronously, but without NCQ there is still a synchronous  
>> bottleneck:  the device<->controller pipe.
> 
> 
> True, but I think that is fairly small compared to no-write-cache-and- 
> no-queuing case. Write-caching is the major win; optimizing the data  
> transfer is only a second-order effect.

Measurements on NCQ in the field show a distinct performance 
improvement...  30% has been measured on Linux.  Nothing to sneeze at.


>>> correctly. ATA disk write caching breaks this guarantee.  To  restore 
>>> filesystem integrity on a careful-write filesystem like   most unix 
>>> filesystems, you have to disable write-caching in the   drive. This
>>
>>
>> False, as Linux has proven:  barriers can be implemented with flush- 
>> cache commands.
>>
>> Disabling write cache is not your only choice, and using flush- cache 
>> gives you better performance than flat-out disabling the  write cache.
> 
> 
> Yes, you're correct; I neglected to include that option. It's not as  
> good as real FUA because it flushes the entire cache, not just the  
> metadata which needs to be written through to the media.

Agreed.

	Jeff

Re: NCQ general question

[Steve Byan]

On Mar 4, 2006, at 2:10 PM, Jeff Garzik wrote:

> Steve Byan wrote:

>>> Data integrity -and- performance.  Performance increases for all   
>>> the standard reasons that an asynchronous pipeline increases   
>>> performance over a synchronous one.
>>>
>>> The write cache means that requests on the device can be  
>>> processed  asynchronously, but without NCQ there is still a  
>>> synchronous  bottleneck:  the device<->controller pipe.
>> True, but I think that is fairly small compared to no-write-cache- 
>> and- no-queuing case. Write-caching is the major win; optimizing  
>> the data  transfer is only a second-order effect.
>
> Measurements on NCQ in the field show a distinct performance  
> improvement...  30% has been measured on Linux.  Nothing to sneeze at.

Wow! 30% is amazing. I'd be interested in knowing how the costs break  
down; are these measurements published anywhere?

Regards,
-Steve
-- 
Steve Byan <smb@egenera.com>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

Re: NCQ general question

[Eric D. Mudama]

On 3/4/06, Steve Byan <smb@egenera.com> wrote:
> On Mar 4, 2006, at 2:10 PM, Jeff Garzik wrote:
> > Measurements on NCQ in the field show a distinct performance
> > improvement...  30% has been measured on Linux.  Nothing to sneeze at.
>
> Wow! 30% is amazing. I'd be interested in knowing how the costs break
> down; are these measurements published anywhere?

Full-stroke random reads with small operations (4k or less) typically
show 75-85% performance improvement, from the ability of a 7200rpm
drive to carve 4ms out of their response time, as well as a huge chunk
of seek distance.

Random writes, since as you said they're already reordered with cache
enabled, don't typically show any sort of increase in desktop
applications.

NCQ FUA writes or NCQ writes with cache disabled should show the same
ballpark performance improvement as random reads in saturated
workloads.  Again however, this is for the full-stroke random case. 
Local area workloads need to be analyzed more thoroughly, and may
differ in performance gain by manufacturer.

--eric

Re: NCQ general question

[Raz Ben-Jehuda(caro)]

Is NCQ supported when setting the controller to JBOD instead of using HW raid?

On 3/5/06, Eric D. Mudama <edmudama@gmail.com> wrote:
> On 3/4/06, Steve Byan <smb@egenera.com> wrote:
> > On Mar 4, 2006, at 2:10 PM, Jeff Garzik wrote:
> > > Measurements on NCQ in the field show a distinct performance
> > > improvement...  30% has been measured on Linux.  Nothing to sneeze at.
> >
> > Wow! 30% is amazing. I'd be interested in knowing how the costs break
> > down; are these measurements published anywhere?
>
> Full-stroke random reads with small operations (4k or less) typically
> show 75-85% performance improvement, from the ability of a 7200rpm
> drive to carve 4ms out of their response time, as well as a huge chunk
> of seek distance.
>
> Random writes, since as you said they're already reordered with cache
> enabled, don't typically show any sort of increase in desktop
> applications.
>
> NCQ FUA writes or NCQ writes with cache disabled should show the same
> ballpark performance improvement as random reads in saturated
> workloads.  Again however, this is for the full-stroke random case.
> Local area workloads need to be analyzed more thoroughly, and may
> differ in performance gain by manufacturer.
>
> --eric
>


--
Raz

Re: NCQ general question

[Jeff Garzik]

Raz Ben-Jehuda(caro) wrote:
> Is NCQ supported when setting the controller to JBOD instead of using HW raid?

1) The two have nothing to do with each other

2) It sounds like you haven't yet read
http://linux-ata.org/faq-sata-raid.html

	Jeff

Re: NCQ general question

[Louis-David Mitterrand]

On Sun, Mar 05, 2006 at 02:29:15AM -0500, Jeff Garzik wrote:
> Raz Ben-Jehuda(caro) wrote:
> >Is NCQ supported when setting the controller to JBOD instead of using HW 
> >raid?
> 
> 1) The two have nothing to do with each other
> 
> 2) It sounds like you haven't yet read
> http://linux-ata.org/faq-sata-raid.html

Hello,

Do you plan on updating your AHCI NCQ patch found in 
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/
It no longer applies cleanly to the latest 2.6.15.x kernel.

Thanks,

Re: NCQ general question

[Jeff Garzik]

Louis-David Mitterrand wrote:
> On Sun, Mar 05, 2006 at 02:29:15AM -0500, Jeff Garzik wrote:
> 
>>Raz Ben-Jehuda(caro) wrote:
>>
>>>Is NCQ supported when setting the controller to JBOD instead of using HW 
>>>raid?
>>
>>1) The two have nothing to do with each other
>>
>>2) It sounds like you haven't yet read
>>http://linux-ata.org/faq-sata-raid.html
> 
> 
> Hello,
> 
> Do you plan on updating your AHCI NCQ patch found in 
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/
> It no longer applies cleanly to the latest 2.6.15.x kernel.

No, but, Jens Axboe and Tejun Heo will have a better version.

	Jeff

Re: NCQ general question

[Louis-David Mitterrand]

On Wed, Mar 08, 2006 at 12:17:51PM -0500, Jeff Garzik wrote:
> Louis-David Mitterrand wrote:
> >
> >Do you plan on updating your AHCI NCQ patch found in 
> >http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/
> >It no longer applies cleanly to the latest 2.6.15.x kernel.
> 
> No, but, Jens Axboe and Tejun Heo will have a better version.

Is it available somewhere?

Re: NCQ general question

[Gentoopower]

Mark Lord wrote:
> Gentoopower wrote:
>> Raz Ben-Jehuda(caro) wrote:
>>> i am thinking of buying a promise card sataII pcix.
>>> they have two types, a card which support NCQ
>>> and another that does not.
>>> What is the bennifit of buying  a card with NCQ tagging ?
>>>   
>> How about: http://en.wikipedia.org/wiki/Native_command_queueing
>
> Yuck.. what a lousy wiki entry.
>
> NCQ vs. TCQ:  NCQ has a much more efficient low-level protocol,
> making the host-side (controller, operating-system) quite a bit
> simpler than with NCQ.
>
> Both use 32-deep queue depths, and neither of them are worth a
> damn on Linux yet.  Except possibly in the libata ahci driver,
> or vendor-provided drivers (open source, even) for some chipsets.
>
> In theory, NCQ/TCQ can speed up a very busy fileserver that is
> handling mostly tiny I/O requests.  Practically no measurable
> benefit for single-user systems.
That's a lousy comment:-)

Single-User systems can have lots of I/O requests too.
If I compile something in the backround, listen to music, while copying
files from one drive to the other.
I also have lots of I/O while booting.
I have two seagates in my box a 160GB 7200.7 and 160GB 7200.9(SATAII
NCQ), using NFORCE4.
I can defintely feel the speed difference between the two drives.

P.S. Just waiting to see NCQ support for my nforce system in libata:-)
>
> Cheers
> -
> 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
>
>



	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: NCQ general question

[Jens Axboe]

On Wed, Mar 01 2006, Gentoopower wrote:
> I have two seagates in my box a 160GB 7200.7 and 160GB 7200.9(SATAII
> NCQ), using NFORCE4.
> I can defintely feel the speed difference between the two drives.

Well that can't be because of NCQ, since it isn't active :-)

> P.S. Just waiting to see NCQ support for my nforce system in libata:-)

Don't hold your breath, it's unlikely to get supported as nvidia wont
open the specs. ahci is a really really nice controller, if you want ncq
I suggest going with that. sil is probably the next in line for ncq
support.

-- 
Jens Axboe

Re: NCQ general question

[Jeff Garzik]

Jens Axboe wrote:
> On Wed, Mar 01 2006, Gentoopower wrote:
>>P.S. Just waiting to see NCQ support for my nforce system in libata:-)
> 
> 
> Don't hold your breath, it's unlikely to get supported as nvidia wont
> open the specs. ahci is a really really nice controller, if you want ncq
> I suggest going with that. sil is probably the next in line for ncq
> support.


Actually.....

* Old-nvidia is ADMA, and I have docs under NDA

* nvidia themselves say they are uninterested in NCQ support for their 
older ADMA controllers, though they don't mind if I implement it

* New-nvidia is AHCI, and thus will support NCQ when AHCI does

* slight correction to the above:  sil24 will do NCQ, I don't think sil does

	Jeff

Re: NCQ general question

[Jens Axboe]

On Wed, Mar 01 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Wed, Mar 01 2006, Gentoopower wrote:
> >>P.S. Just waiting to see NCQ support for my nforce system in libata:-)
> >
> >
> >Don't hold your breath, it's unlikely to get supported as nvidia wont
> >open the specs. ahci is a really really nice controller, if you want ncq
> >I suggest going with that. sil is probably the next in line for ncq
> >support.
> 
> 
> Actually.....
> 
> * Old-nvidia is ADMA, and I have docs under NDA
> 
> * nvidia themselves say they are uninterested in NCQ support for their 
> older ADMA controllers, though they don't mind if I implement it

So it's up to you if it'll happen or not. I'm sure people would
appreciate nforce NCQ support :-)

> * New-nvidia is AHCI, and thus will support NCQ when AHCI does

Great! The sane choice, for both producer and consumer.

> * slight correction to the above:  sil24 will do NCQ, I don't think sil does

Ok, it was more of an umbrella sil label, I haven't looked into specific
models.

-- 
Jens Axboe

Re: NCQ general question

[Raz Ben-Jehuda(caro)]

i can see the NCQ realy bother people.

i am using a promise card sata TX4 150.
does any of you has a patch for the driver
so it would support NCQ ?

On 3/1/06, Jens Axboe <axboe@suse.de> wrote:
> On Wed, Mar 01 2006, Jeff Garzik wrote:
> > Jens Axboe wrote:
> > >On Wed, Mar 01 2006, Gentoopower wrote:
> > >>P.S. Just waiting to see NCQ support for my nforce system in libata:-)
> > >
> > >
> > >Don't hold your breath, it's unlikely to get supported as nvidia wont
> > >open the specs. ahci is a really really nice controller, if you want ncq
> > >I suggest going with that. sil is probably the next in line for ncq
> > >support.
> >
> >
> > Actually.....
> >
> > * Old-nvidia is ADMA, and I have docs under NDA
> >
> > * nvidia themselves say they are uninterested in NCQ support for their
> > older ADMA controllers, though they don't mind if I implement it
>
> So it's up to you if it'll happen or not. I'm sure people would
> appreciate nforce NCQ support :-)
>
> > * New-nvidia is AHCI, and thus will support NCQ when AHCI does
>
> Great! The sane choice, for both producer and consumer.
>
> > * slight correction to the above:  sil24 will do NCQ, I don't think sil does
>
> Ok, it was more of an umbrella sil label, I haven't looked into specific
> models.
>
> --
> Jens Axboe
>
>


--
Raz

Re: NCQ general question

[Jens Axboe]

(don't top post)

On Thu, Mar 02 2006, Raz Ben-Jehuda(caro) wrote:
> i can see the NCQ realy bother people.
> 
> i am using a promise card sata TX4 150.
> does any of you has a patch for the driver
> so it would support NCQ ?

I don't know of any documentation for the promise cards (or whether they
support NCQ). Does the binary promise driver support NCQ?

Jeff likely knows a lot more.

-- 
Jens Axboe

Re: NCQ general question

[Jeff Garzik]

Jens Axboe wrote:
> (don't top post)
> 
> On Thu, Mar 02 2006, Raz Ben-Jehuda(caro) wrote:
> 
>>i can see the NCQ realy bother people.
>>
>>i am using a promise card sata TX4 150.
>>does any of you has a patch for the driver
>>so it would support NCQ ?
> 
> 
> I don't know of any documentation for the promise cards (or whether they
> support NCQ). Does the binary promise driver support NCQ?
> 
> Jeff likely knows a lot more.

The "sata2 tx4 150" supports NCQ, and I have docs.  "sata tx4 150" does 
not support NCQ.

	Jeff

Re: NCQ general question

[Raz Ben-Jehuda(caro)]

Thank you Mr Garzik.
Is there a list of all drivers and there features they give ?

Raz.

On 3/2/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> Jens Axboe wrote:
> > (don't top post)
> >
> > On Thu, Mar 02 2006, Raz Ben-Jehuda(caro) wrote:
> >
> >>i can see the NCQ realy bother people.
> >>
> >>i am using a promise card sata TX4 150.
> >>does any of you has a patch for the driver
> >>so it would support NCQ ?
> >
> >
> > I don't know of any documentation for the promise cards (or whether they
> > support NCQ). Does the binary promise driver support NCQ?
> >
> > Jeff likely knows a lot more.
>
> The "sata2 tx4 150" supports NCQ, and I have docs.  "sata tx4 150" does
> not support NCQ.
>
>         Jeff
>
>
>
>


--
Raz

Re: NCQ general question

[Jeff Garzik]

Raz Ben-Jehuda(caro) wrote:
> Thank you Mr Garzik.
> Is there a list of all drivers and there features they give ?

Yes: http://linux-ata.org/sata-status.html

	Jeff