On Mon, 2007-12-10 at 16:33 +0900, Tejun Heo wrote: > There's one thing we can do to improve the situation tho. Several > drives including raptors and 7200.11s suffer serious performance hit if > sequential transfer is performed by multiple NCQ commands. My 7200.11 > can do > 100MB/s if non-NCQ command is used or only upto two NCQ > commands are issued; however, if all 31 (maximum currently supported by > libata) are used, the transfer rate drops to miserable 70MB/s. > > It seems that what we need to do is not issuing too many commands to one > sequential stream. In fact, there isn't much to gain by issuing more > than two commands to one sequential stream. You're entering an area of perennial debate even for SCSI drives. What we know is that for drives whose firmware elevator doesn't perform very well is that a lower TCQ depth (2-4) is better than a high one, the only use tags have being to saturate the transport. For high end arrays and better performing firmware drives, the situation is much more murky. It boils down to whose elevator do you trust, the drive/array's or the kernel's. If the latter, then you want a depth of around 4 and if the former, you want a depth as high as possible (arrays like 64-128). Given the way IDE drives are made, I'd bet they fall into the category of firmware elevator that doesn't perform very well, so you probably want a low NCQ depth with them (just sufficient to saturate the transport, but not high enough to allow the drive to make too many head scheduling decisions). James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
