Talk:Native Command Queuing

Inaccuracies, proposal for replacement/move

• The article should clearly state whether the benefits of NCQ apply to SSD drives (and if they apply, in what way), or if NCQ only has meaning for mechanical disks. 77.38.47.181 (talk) 08:25, 9 January 2013 (UTC)
• Nothing here (well, nothing remotely correct, anyway) except "it's for SATA" is particular to NCQ. There should be a general TCQ/Command Queueing and Reordering article, and once there is, it would probably be best to discuss the different types (host-based, NCQ, etc) there and have a redirect to that page from NCQ rather than have separate articles.
• The reduced distance traveled by actuators in drives using any sort of TCQ has only a negligible benefit for the endurance/reliability of hard drives. This is a side benefit rather than a primary design point.
• Disk access patterns, not the number of threads or processes running, are what determine to what extent TCQ is a benefit (it can be a detriment, as it has noticable overhead costs); witness storagereview.com's conclusion when finding that TCQ (whether host-based or NCQ) reduced single-user performance across the board: "Remember that no matter how sophisticated the multitasking and multithreading get in a single-user machine, access patterns (highly-localized vs. highly-random) and queue depths (mostly-low with an occasional burst vs. consistently-higher) remain fundamentally different from a multi-user server."
• NCQ is *NOT* specific to AHCI host controllers, much less to Intel's drivers for Windows. Nor is the topic specific to the category "IBM PC Compatibles".
• The linked article, from which some of the current content here has been shamelessly cribbed, is fundamentally messed up (imprecise, rambling, and in a few cases just plain wrong) and there's no good excuse for using the heavily self-promoting-ad-laden "helpful buying guide" of a PC vendor rather than an explanation from either those developing the technology or an independent review site or somesuch.

--Prodicus

3.1415926535897932, Which intel employee wrote this article?

If there are so many people who know enough about NCQ to distpute the validity of the claims in the article, why has no one yet taken the time to rewrite the article?

We're lazy bastards

Get off your asses and start writing some stuff instead of being a slimey puke

This article has been tagged as "inaccurate" for months now, and I can't find most of Prodicus' objections to specific facts back in the article, as it has been helpfully edited by an anonymous user. I'm removing the tag on those grounds. If there are any more objections of this highly specific nature, please feel very free to {{sofixit}}. JRM · Talk 15:24, 2005 Jun 18 (UTC)

See http://www.tomshardware.com/storage/20041116/command_queuing-01.html for a simple differentiation between TCQ and NCQ

Spelling

Jareha 06:29, 19 Apr 2005 (UTC) Not sure if anyone else has realized this, but queuing is mispelled.

Both queueing and queuing are valid spellings. Queueing seems to be preferred over queuing as part of the general "all en-US spellings must go because the US is just so out of fashion" policy.--Prodicus

• The article should be moved to NCQ with the more widely used (including in the US) spelling. The existing three external links all use "queuing". Objections to a move? Obey 16:52, 18 September 2005 (UTC)

I've moved the article because of "many more hit on Google" and because US spelling is the defacto in the computing industry. (I usually prefer UK spelling, so I don't think I'm biased here). --R.Koot 11:35, 7 November 2005 (UTC)

How to compare to SCSI TCQ

Some people seem to think that all TCQ, including SCSI TCQ, is inferior to NCQ. I'm trying to find a suitably polite, NPOV way to say that "SCSI doesn't have NCQ because they got TCQ right in the first place." If anyone can manage it, please contribute.

To my knowledge NCQ is inferior to TCQ whenever SCSI or ATA. Basically NCQ is TCQ reduced (has a shorter queue for instance).--Anss123 19:13, 3 October 2006 (UTC)

The shorter queue is not a factor, benchmarks that take advantage of NCQ and TCQ find tend to find them Equally usable —The preceding unsigned comment was added by 84.95.126.124 (talk) 09:45, 24 December 2006 (UTC).

Actually, ATA TCQ is a piece of trash which drives up CPU utilization without much performance benefit. See what I wrote in Tagged Command Queuing about it. NCQ is a newer version of TCQ which looks almost exactly like SCSI TCQ, except that NCQ has a shorter queue depth than SCSI because SCSI can manage many disks at once while SATA can only manage one disk per link, and that NCQ allows a drive to withold completion interrupts to allow it to retire several commands at once instead of having to send an interrupt for each and every command sent. Having a longer queue depth only amounts to diminishing returns when dealing with one disk. SCSI TCQ got it right the first time around (except for the requirement that each command must be retired separately). ATA TCQ got it wrong in every count possible because it had the constraint that PATA host bus adapters must act like ISA bus devices. NCQ got it right for its intended purpose: managing one disk at a time. It is inapporpriate for a storage network, where a longer queue depth would help. For managing a single disk, NCQ is the best protocol. For managing more than one disk, SCSI TCQ is the best protocol. ATA TCQ would go to BJAODN along with WEP if they were not real world protocols. Jesse Viviano 18:42, 16 March 2007 (UTC)

Fedora Core's 2.6.18 kernel provides NCQ support

Here's an excerpt from my kernel messages:

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 0/32)

As you can see, NCQ is enabled and working. Hard drive works like a champ.

---

It's in mainline now.

Disadvantages, criticism.

This article is more a fan page listing benefits than an encyclopedic article.

I'd gather that NCQ in most normal applications, like games, and with defragmented (if applicable) drive is infact slower because of the overhead required by the intelligent ordering increaseas the latency of the IOs. Not to mention the fact that NCQ always brings in variability to performance, even on linear reads, because of the re-ordering schemes.

For example: Maxtor Diamond Max 10 's NCQ enabled performance in games is in some cases radically slower than one with disabled NCQ, in others it's marginally faster.
The majority of our benchmarks showed slower performance levels with NCQ enabled, although some of our benchmarks do show some rays of home. I liken NCQ to Hyper-Threading – you really don’t see performance increased when you’re running a single application, but when you’re running a lot of applications simultaneously, things just “feel” smoother.

- G3, 12:32, 17 December 2006 (UTC)

The gamepc.com review you linked to is from 2004 and mentions that the DiamondMAX 10 drive was the first to offer NCQ. I'm inclined to think that things may well have changed since then. Do you have any newer benchmarks comparing NCQ being enabled and disabled? Wrs1864 00:14, 5 January 2007 (UTC)

It's difficult to find newer un-synthetic benchmarks with defragged drive. In multi-threaded random reads & writes NCQ does (should) improve performance, ín certain cases by a significant margin (up to 50-100% boost). However, if your HDD is in orderly state and the data you're reading is linearly located in a certain area on the disk then I fail to see how intelligent ordering could do any better. However, I did dig this(apparently from 2005) up:

"We believe that NCQ is an enterprise specification," says Sherri Besser, senior director, product marketing for Western Digital. "It makes no sense in desktops. In fact, in the benchmarks we've been running, NCQ hurts desktop benchmark performance, especially in sequential reads and writes."

Also, Tom's Hardware has a nice comparison of drives and it clearly shows that what NCQ or SATA (in most cases) do not do is improve performance dramatically. (note: all are synthetic benchmarks & most are also random access oriented ones) - G3, 04:14, 12 January 2007 (UTC)

This quote does appear to be in favour of NCQ, and it's making a point about the reliance on benchmarks in relation to real-world use. Moreover, the linear-access situations where reordering can do harm are so fast that in any real-world situation (ie., where data has to be processed rather than thrown away [the obvious exception being file transfers]) they're over in no time and a small penalty means very little. You would have to be crazy to think that some firmware and protocol trickery is going to make a hard drive substantially faster in its optimal case. The focus of the technology is in mitigating the harm of the pessimal cases; so that should probably be the focus of this article. --ToobMug (talk) 13:05, 6 January 2008 (UTC)

Copyright violation reversion

I reverted the article to the version here because subsequent versions were copyright violations from http://www.highpoint-tech.com/PDF/Native_Command_Queuing-A_Primer.pdf. Jesse Viviano 04:14, 2 January 2007 (UTC)

Is the illustration backwards?

As of today, 2007-Oct-18, it seems to me that the illustration is mislabeled. The red picture labelled "no NCQ" versus the green picture "NCQ" seem to be backwards. The desired optimization minimizes head movement. The illustration is confused and seems to indicate that the head is supposed to move real fast so it can pick up several sectors in a single disk revolution -- way wrong. Mister-al-x 20:44, 18 October 2007 (UTC)mister-al-x

You have a point, but the illustration is only meant to show how a hard drive can optimize its read order as it sees fit - in this case taking advantage of faster head movement.

--Anss123 21:23, 18 October 2007 (UTC)

It might be better illustrated if you were to consider two independent streams of unfragmented data (eg., old data being swapped out while new data is being loaded into memory). Unoptimised you may have to switch back and forth several times, and optimised you would read many read sectors of one stream and then many sectors of another. --ToobMug (talk) 12:36, 6 January 2008 (UTC)

The illustration does have a point: on a 7,200 RPM drive one revolution takes 1/120th second: ~8.3 msec. A very fast drive can skip to an adjacent track in less than .5 msec, so if the other track is not too far away it actually might be faster to pick up neighbor sectors 'en passant'. Zac67 (talk) 21:07, 11 June 2008 (UTC)

Are you sure that the .5 msec figure can actually be realized in the given situation? I tend to think that a figure like that can only result as an average cylinder skip time when the stepping motor is at its peak velocity. Give sources and I'll stand corrected. --217.232.248.199 (talk) 12:41, 30 September 2008 (UTC)

Just take a look at any current harddrive's spec sheet. E.g. track to track seek time of Barracuda ES is .8 msec, a Savvio 10k 2.5" is supposed to reach even .2 msecs. At full sweep speed a track is covered in much less than 1 µsec! (assumed 20,000 tracks, 8 ms avg seek time (1/3 sweep), linear acceleration/deceleration: 8 ms / 2 : (20k/3) = .6 µsec). Stepping motors have been out of fashion for 20 years - it's linear actuators since. Plus steppers have no peak speed - they operate at constant stepping frequencies. --Zac67 (talk) 16:22, 5 October 2008 (UTC)

I added this to the caption: "Without NCQ, the blocks are accessed in the order in which they were requested. With NCQ, the requests are reordered by angular position, taking one less revolution of the disk to scan all four blocks". Hope it's more clear now. --arielCo (talk) 03:37, 18 October 2009 (UTC)

It is more clear, but it is more clearly wrong. The whole point of NCQ is that so long as any explicit ordering constraints are respected the rest is left up to the device to sort out as it sees fit. Stating in such unambiguous terms that requests are resorted by angular position is highly misleading - any hard drive can complete a full rotation in much less time that it takes to seek an appreciable distance over the platter. If a drive does the kind of thing depicted in the illustration it will only be for neighbouring tracks - it is not going to go between the 1st and 10,000th cylinder and back again in the space of one revolution. What an NCQ drive will do in practice is undefined but the biggest benefits are in reordering requests by cylinder to avoid thrashing. CrispMuncher (talk) 20:32, 18 October 2009 (UTC).

Valid point. It is important to use command queueing to give the drive the freedom to reorder commands rather than having to stick to the more-or-less efficient order provided from the host. Only the drive knows its hardware well enough to decide. -- Zac67 (talk) 17:44, 14 February 2010 (UTC)

I like the new caption. Still, I have one doubt: Is NCQ always about minimizing revolutions? E.g., at 7200 rpm one revolution is ~8.3 ms, and a typical avg seek time is 7-9 ms. arielCo (talk) 13:30, 15 February 2010 (UTC)

NCQ would've been a much bigger deal for IDE/PATA since on a master/slave setup it would have enabled both drives to work much more simultaneously instead of a command for one disk haveing to wait for the previous command on the other. But that didn't (really) happen. NCQ is not about minimizing revolutions directly, it's about speeding things up by lowering overall latency. --Zac67 (talk) 21:55, 15 February 2010 (UTC)

Ambiguity

The article reads: "a generic AHCI drivers" as of 15:32, 6 August 2008 (UTC).

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: withdrawn. ErikHaugen (talk | contribs) 07:21, 8 January 2012 (UTC)

---

Native Command Queuing → Native command queuing –

Per WP:MOSCAPS ("Wikipedia avoids unnecessary capitalization") and WP:TITLE, this is a generic, common term, not a propriety or commercial term, so the article title should be downcased. In addition, WP:MOSCAPS says that a compound item should not be upper-cased just because it is abbreviated with caps. Lowercase will match the formatting of related article titles. Tony (talk) 14:17, 1 January 2012 (UTC)

• Meh Would make sense if used as a generic term (although, then shouldn't it be "native command-queuing"?). Seems to be written using capitals significantly more often though, including in sources used in the articles (e.g. http://www.tomshardware.com/reviews/command-queuing-turbo-charge-sata,922-2.html). —Ruud 22:40, 1 January 2012 (UTC)

• Comment – Tony's observation makes sense for the way the article is written, but if you look at the referenced white paper, it says it's a protocol, not a technology. One's a specific item, the other a generic. Tony has accepted that one doesn't downcase protocol names. If someone will fix the article, this will go away. Dicklyon (talk) 22:52, 1 January 2012 (UTC)
  • Yes, if it has to be upcased, we need to know it's a protocol in in the article—preferably at the top. Tony (talk) 01:19, 2 January 2012 (UTC)
• Oppose - it's not a generic term but a protocol (or rather an extension to one). - Zac67 (talk) 16:11, 2 January 2012 (UTC)

So is someone who knows the topic going to fix up the generic theme of the article text? If that is done, I'll gladly withdraw this RM. Tony (talk) 03:10, 3 January 2012 (UTC)

Sorry, can't exactly make out a too generic theme. Do you have specific issues? Zac67 (talk) 11:18, 6 January 2012 (UTC)

You're right, I'm being muddle-headed. I think the RM should be withdrawn. Tony (talk) 15:25, 6 January 2012 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.