Native Command Queing in SATA 1.0?

[sergentshrek]

I've seen lately that Maxtor and Seagate have released drives with NCQ enabled, however, I was under the understanding that NCQ was a SATA II. Will the drive or the OS handle the commands as they are threaded in, or is this just another early release of a technology we can't yet use or take advantage of? Where else can I learn more about subject? I've read both white papers from Maxtor and Seagate, but neither seem to approach the subject of using NCQ and SATA 1.0 standards. Any info is greatly appreciated.

 

[sjonnie]

<i>>I was under the understanding that NCQ was a SATA II</i>

NCQ is implemented in the SATAII standard. However, certain manufacturers have pre-empted the SATAII standard by including it with SATAI.

<i>>Will the drive or the OS handle the commands as they are threaded in</i>

It's a hardware implementation so in theory no software is needed. The drivers and maybe the BIOS associated with the controller chip will allow you to turn NCQ off (or on should you feel the need).

<i>>we can't yet use or take advantage of?</i>

Enabling NCQ causes the hard disk performance to drop in desktop systems.

<i>>Where else can I learn more about subject?</i>

Google, where else?

 

[jammydodger]

Enabling NCQ causes the hard disk performance to drop in desktop systems.

Really? You know of any articles on this?

 

[RichPLS]

I have heard this too, but it is in the realm of 1 to 2% and in specific areas of performance, where in other areas it gains a greater lead with it enabled.

<A HREF="http://www.lostcircuits.com/hdd/hdd8/non-queued.gif" target="_new"> Non-Queued </A>


<A HREF="http://www.lostcircuits.com/hdd/hdd8/queued.gif" target="_new"> Queued </A>

NCQ and SCSI Tagged Command Queing really come into their own in a multiuser environment, or heavy database access (often one and the same) where the data being concurrently accessed is spread out all over hell and back you can normally address that by where your putting that data in a single user environment aps that require performance closer to the OD, stuff that requires concurrent access on seperate channels\HDDs the objective it to avoid having to swing that arm through too many degrees of arc in the first place.

<pre><font color=red>°¤o,¸¸¸,o¤°`°¤o \\// o¤°`°¤o,¸¸¸,o¤°
And the sign says "You got to have a membership card to get inside" Huh
So I got me a pen and paper And I made up my own little sign</pre><p></font color=red>

 

[RichPLS]

It was not very long ago that most elevators approached the target floors in the order in which the buttons were pressed – a rather inefficient way of servicing all commands, and, moreover, it involved an enormous waste of time for going back and forth between the different target locations. The interesting thing is that this is exactly the method employed by most contemporary HDDs.

Elevators have evolved over the last decades to understand that the most economic way of servicing the different outstanding commands will have to include reordering and rescheduling of certain commands. A side effect is faster speed and because of the overall reduced workload, less mechanical wear and tear that directly translates into better reliability and higher lifespan / endurance of all parts.

The elevator example is actually quite fitting, everybody knows that it is possible to enter the elevator on the third floor and then push the 7th floor button, even if the next floor that was originally selected was e.g. the 10th floor. As long as the command comes in time to be inserted into the ongoing workflow before the target floors are passed it is possible to reorder the commands and stop at the next floor. This is called dynamic reordering of a command queue and coincidentally the essence of the Serial ATA Native Command Queuing scheme.

To take the elevator example a bit further: Somebody may have just missed a target floor, and, therefore, will have to hit that particular floor on the way back. Most elevators will clear the commands at the point of turnaround, however, the more advanced units will keep track of entered commands and defer their execution by creating the next queue already during the execution of the first. This decision-making as to into which queue any newly entered command may fit or, by extension, whether there is another, more efficient way of executing the entire outstanding workload is also part of the NCQ scheme written into the SATA II specifications.


<pre><font color=red>°¤o,¸¸¸,o¤°`°¤o \\// o¤°`°¤o,¸¸¸,o¤°
And the sign says "You got to have a membership card to get inside" Huh
So I got me a pen and paper And I made up my own little sign</pre><p></font color=red>

 

[sjonnie]

<i>> Really? You know of any articles on this?</i>

Yes really. Anywhere really. Tom's, Xbitlabs, Anandtech, StorageReview - all show the same thing, NCQ is only usefull with a queue depth >16 which is irrelevant for a desktop.

<i>>it is in the realm of 1 to 2% and in specific areas of performance, where in other areas it gains a greater lead with it enabled.</i>

<A HREF="http://www.storagereview.com/php/benchmark/compare_rtg_2001.php?typeID=10&testbedID=3&osID=4&raidconfigID=1&numDrives=1&devID_0=259&devID_1=267&devCnt=2" target="_new">1-2% </A>eh? I calculate 20% boost to benchmarks in the Desktop Suite and Gaming Benchmarks, HighEnd WinMark 99 seems evenly split if a little screwed and the ServerBenchmarks do exactly what you'd expect, at low queue depth TCQ reduces performance and at high queue depth (>16) it increases it.

 

[sjonnie]

The elevator example is all very well, but irrelevant when there is only ever 1 person in the elevator. Run perfmon and see for yourself. I'm running it now on my eMule drive. It's currently uploading at 101.0Kb/s and downloading at 20Kb/s. The disc queue is....errr...0. Yes zero, zilch, nothing, squat. Every request to the drive is being instantly dealt with so queuing doesn't even come into the equation.

The second reason queuing doesn't always help is because of latency vs. seek time. Latentcy is what occurs when a drive moves to the correct track on the drive but has to wait for the cylinder to come around. In the <A HREF="http://www.lostcircuits.com/hdd/hdd8/queued.gif" target="_new">picture</A> of a queued drive access there is no way the drive could access 1 then 4 because the seek time would be greater than the latency, i.e. the head would take maybe 3ms to get across there whereas a 10k rpm drive completes one revolution every 6ms so the drive will have turned past data block 4 in those 3 milliseconds. So the best order would more likely be 1,3,2, +1 revolution then 4 and 5 which isn't that much faster than doing 1,2,3,4,5. However, the more drive requests you get, say you extend the queue to 16 requests, the more likely you are to find requests on the same track or adjacent tracks (track-to-track seek time is about 0.4ms) where the seek times are lower than the latency and queuing can work effectively.

 

[jammydodger]

TCQ is what current (non NCQ) IDE drives use correct? I woulda thought that NCQ would deliver a performance boost from all applications, they way I understand it it seems a lot more efficient than the standard method.

 

[Rugger]

TCQ is used primarily in SCSI drives and now on the Raptors. They both have the same <b>basic</b> concept - to more efficiently process requests for info on the HDD and would shine in heavy HDD access environments. If there is no queue, then there will be no performance increase from NCQ/TCQ.

__________________________________________________
<font color=red>You're a boil on the arse of progress - don't make me squeeze you!</font color=red>

 

[jammydodger]

So what are the differences between TCQ and NCQ then? SO the majority of IDE drives (apart from the very new ones) have no form of command queueing what so ever?

 

[Rugger]

Here is a <A HREF="http://www.tomshardware.com/storage/20041116/index.html" target="_new">THG Command Queueing Article</A>. Pretty good read.

You are correct - most of the drives have no form of command queueing.

__________________________________________________
<font color=red>You're a boil on the arse of progress - don't make me squeeze you!</font color=red>

 

[fishmahn]

More accurately (or maybe more technically...), All older drives have a fifo queue - first request in is the first request filled (or out).

 

[Rugger]

thank you for the clarification...queued, but not using TCQ or NCQ.

__________________________________________________
<font color=red>You're a boil on the arse of progress - don't make me squeeze you!</font color=red>