Navigate: Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home	.	.
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ Search Prices:

Different Queues in Different Standards

Originally, command queuing was introduced to the SCSI specifications as adaptation towards an multi Host / multi target environment where each host can request multiple sets of data from multiple sources and further prioritize the different workloads. This is done by allowing three different types of queue, namely the Simple Queue, the Ordered Queue and the so-called Head of Queue. Simple queues allow the drive to reorder all commands in any arbitrary sequence suitable to the drive. However, there are situations where priorities need to be changed, in that case, the controller can champion a command by changing its status to it a Head of Queue. Head of Queue commands are executed in a last-in-first-out (LIFO) fashion.

The LIFO way of prioritizing is a very elegant way of allowing the controller to do “business as usual” with the possibility of interrupting any given workload if an urgent task comes along, simply by assigning Head of Queue attribute to the respective command. Since it was the last command issued, it will then be the first to be executed.

The last form of queuing, that is, the Ordered Queue is relevant only in complex systems. Ordered queues do not allow the drive any reordering. The purpose is to avoid “confusion” if multiple requests of hierarchically ordered commands are issued simultaneously by several hosts. That is, if by chance some of the outstanding commands are “interleaved” with respect to the locality of their LBAs, even though they belong to different threads, it might cause problems in the hierarchy of the data flow to the host. One trivial example would be the delivery of data before the instructions in e.g. a streaming video editing task.

The new 2.5" Fujitsu MHT2060AH SATA drives support Native Command Queuing while running at 5400 rpm and boasting an 8 MB drive cache. These drives are lightning-fast and will probably be the pacemakers for the nex generation of HDDs.

The Hardware Behind Queuing

We have talked so far about queuing in the context of illustrating the principle behind it and we have mentioned that queuing means an ordered stack of software commands. We have looked into some of the protocols and routines and Frame Information Structures in some earlier articles but we have not looked at the hardware necessary for queuing. In general, a queue is a pipeline or serialized buffer. In the simplest case, the data are going in on one end and coming out on the other end – the classical implementation of a first-in-first-out (fifo) pipeline - however, reordering requires bypass switches for out of order execution of commands based on priorities. Those priorities are set by the drive itself in most cases (unless a Head of Queue attribute is assigned by the controller)

Queue Depth against The Rest Of The World

Each command that is “queued” also needs to be tracked by its initiator/target/logical unit/queue (ITLQ) nexus tag value to keep record of what has been finished and what is still outstanding in terms of device X to host Y transfers. This is where the term SCSI Tagged Command Queuing (TCQ) originates. Because of the complexity of the ITLQ nexus, SCSI needs to support a queue depth of up to 256 levels, equivalent to 256 individual pipeline stages or outstanding commands.

Desktop ATA specifications only support up to 32 levels, which is more than enough, especially in view of the fact that most consumer operating systems will not even support more than a few outstanding commands. Moreover, piling up of outstanding commands can easily lead to a bottleneck situation, which then proliferates throughout an entire workload session, not to mention the price overhead in the case of commodity drives.

In SCSI, the situation is different altogether, and the biggest difference is actually the fact that a SCSI RAID storage box will appear to the system as a single device. Therefore, the individual queue depths of all devices will combine into a single, extra-deep queue. Conversely, this means that even if the queue depth per device is limited to 32 levels, they can still combine to up to 256 levels. It is rather obvious, though, why on the device level (the Logical Unit in the ITLQ acronym) a 32 stage pipeline is as deep as what is reasonable to support by any supersystem.. Furthermore if queues are deeper, they will fill up at one point and that means a higher number of outstanding commands, which again could result in a bottleneck situation. Keep in mind that a poorly implemented queue is not worth the silicon it is made from.

next page:    => Hard Disc Drive Architecture VI: The Big Picture =>