Editing Native Command Queuing (section)

=== Performance ===
A 2004 test with the first-generation NCQ drive (Seagate 7200.7 NCQ) found that while NCQ increased IOMeter performance, desktop application performance decreased.<ref>{{cite web|url=http://techreport.com/review/7750/seagate-barracuda-7200-7-ncq-hard-drive/13 |title=Seagate's Barracuda 7200.7 NCQ hard drive - The Tech Report - Page 13 |date=17 December 2004 |publisher=The Tech Report |access-date=2014-01-11}}</ref> One review in 2010 found improvements on the order of 9% (on average) with NCQ enabled in a series of Windows multitasking tests.<ref>{{cite web|url=http://techreport.com/review/8624/multitasking-with-native-command-queuing/5 |title=Multitasking with Native Command Queuing - The Tech Report - Page 5 |date=3 August 2005 |publisher=The Tech Report |access-date=2014-01-11}}</ref>

NCQ can negatively interfere with the operating system's [[I/O scheduler]], decreasing performance;<ref name="young">{{Cite journal |last1=Yu |first1=Y. J. |last2=Shin |first2=D. I. |last3=Eom |first3=H. |last4=Yeom |first4=H. Y. |year=2010 |title=NCQ vs. I/O scheduler |journal=ACM Transactions on Storage |volume=6 |pages=1–37 |doi=10.1145/1714454.1714456 |s2cid=14414608}} [http://www.cs.albany.edu/~sdc/CSI500/Fal10/DiskArmSchedulingPapers/a2-yu.pdf]</ref> this has been observed in practice on [[Linux]] with [[RAID-5]].<ref>{{cite web|url=http://serverfault.com/questions/305890/poor-linux-software-raid-5-performance-with-ncq |title=hard drive - Poor Linux software RAID 5 performance with NCQ |publisher=Server Fault |access-date=2014-01-11}}</ref> There is no mechanism in NCQ for the host to specify any sort of deadlines for an I/O, like how many times a request can be ignored in favor of others. In theory, a queued request can be [[Resource starvation|delayed by the drive an arbitrary amount of time]] while it is serving other (possibly new) requests under I/O pressure.<ref name=young/> Since the algorithms used inside drives' firmware for NCQ dispatch ordering are generally not publicly known, this introduces another level of uncertainty for hardware/firmware performance. Tests at Google around 2008 have shown that NCQ can delay an I/O for up to 1–2 seconds. A proposed workaround is for the operating system to artificially starve the NCQ queue sooner in order to satisfy low-latency applications in a timely manner.<ref>Gwendal Grignou, NCQ Emulation, FLS'08 [https://www.usenix.org/legacy/publications/login/2008-06/openpdfs/lsf08reports.pdf talk summary (p. 109)] [https://www.usenix.org/legacy/event/lsf08/tech/IO_grignou.pdf slides]</ref>

On some drives' firmware, such as the [[Western Digital Raptor|WD Raptor]] circa 2007, [[Disk buffer|read-ahead]] is disabled when NCQ is enabled, resulting in slower sequential performance.<ref>{{cite web|url=https://lkml.org/lkml/2007/4/3/159 |title=Mark Lord: Re: Lower HD transfer rate with NCQ enabled? |publisher=LKML |date=2007-04-03 |access-date=2014-01-11}}</ref><!-- note that Mark Lord, as one of the major IDE driver developers in Linux is reliable source for this kind of info; see his bio at http://www.linuxsymposium.org/2010/view_bio.php?id=2652 -->

SATA [[solid-state drive]]s profit significantly from being able to queue multiple commands for parallel workloads. For PCIe-based [[NVMe]] SSDs, the queue depth was even increased to support a maximum of 65,535 queues with up to 65,535 commands each.