＋设为首页 ＋添加到收藏夹
在serial ata ⅱ对serial ata 1.0所做的诸多功能扩展中，只有一项是与性能密切相关的，它就是本机命令排队（native command queuing，也称全速命令排队，简写为ncq）。借助sata 1.0改进的dma机制，sata ⅱ本机命令排队结束了pata命令排队可有可无的尴尬历史，能够更好地满足入门级服务器与网络存储设备的要求，也顺应了pc应用环境向多线程发展的趋势。
pata排队难有作为 【相关文章:Oracle性能调优原则】
并行ata（pata）命令排队协议1997年就被加入ata/atapi-4规范，可直到现在仍仅有一家硬盘厂商（hgst，原来的ibm）提供支持该协议的产品。难道是pata命令排队实现起来太过复杂？答案当然是——非也。 【扩展阅读:Unix环境下的Oracle调优】
组成pata排队协议的命令包括read dma queued(ext)、write dma queued(ext)与service，其中后者是出于pata dma的总线从属性需要。前面我们已经介绍过，pata是非对等的协议，也即硬盘不能主动与主机通信，必须由主机定期交替轮询（同一通道内的）主盘与从盘。这样一来，硬盘在接收到来自主机的命令后，要么立即执行，要么必须通过设置注意标志与service位来通知主机何时准备就绪执行命令。主机发现service位后，会发出一条service命令，以便从硬盘得到将执行哪一条待执行命令的信息。 【扩展信息:保持Oracle数据库的优良性能】
在这个即将被抛弃的时刻，pata的“罪恶”自然是罄竹难书。如此说来，再多拎出一条似乎也不能算落井下石。
由于队列的客观属性决定了其中至多有一条命令能够立即执行，因此在深度大于1的队列中service命令不可避免。由于service位不包含任何对即将执行命令的识别信息，所必需的命令识别信息要以标记值的形式与数据请求一同传输，而且仅供主机用以设置dma引擎与接收数据缓冲区，主机不能预先掌握硬盘所设置的辅助位来自哪条命令，数据传输周期开始前也无法设置dma引擎。本来最清楚数据存放在何处与怎样访问的硬盘，现在反倒被置于完全被动的地位，有关数据传输的所有准备工作与决策都是由主机做出的，自己只剩下设置service位，等待主机下一次查询的份儿。最终的结果是，受pata dma的总线从属性限制，pata命令排队带来的性能改善，很轻易地就被协议开销抹杀了。在队列深度较浅的时候，性能甚至还比不排队的情况有所下降——连“聊胜于无”都算不上。
所以，尽管接收到来自主机的命令就执行（而不是排队）看起来很傻，可是pata硬盘的设计者们基本上别无选择。没有命令排队（有也发挥不了多大作用）的后果就是，随着并发访问程度的提高，pata硬盘与scsi硬盘之间的性能差距被越拉越大（见图）。
560)this.style.width=560; onmousewheel = javascript:return big(this) height=479 src="/files/uploadimg/20060118/1752200.jpg" width=550 border=1>
pata硬盘的iops性能随队列深度提高的幅度明显不及scsi硬盘
在传统的pc单线程应用中，pata硬盘可以按照主机软件安排的顺序执行命令，因此没有命令排队还不是很严重的问题。但是，随着超线程技术的出现，多线程应用将逐渐在pc领域普及，对硬盘端排队能力的需求渐趋迫切，sata ⅱ本机命令排队可谓生逢其时。
... 下一页