Talk:Native Command Queuing

From Wikipedia, the free encyclopedia

Contents

[edit] Inaccuracies, proposal for replacement/move

  • 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

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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)