Raptors and command queuing

-FX-

n00b
Joined
Aug 4, 2003
Messages
58
Has anybody configured their drive for command queuing yet? I just got a Rapter yesterday, but im run'n it off my sata controller on my p4c800-e...wanted to know if anybody out there is using a card to accomplish this feature, and what card that would be...thx
 
From what I've heard there is only one SATA controller on the market that uses command queuing.

Plus, it doesnt do ANYTHING for you unless you are using the hard drive in a server and have a dozen or more users pulling data from it at random times.

For the single user, or even small network, the performance increase would be impossible to even measure.
 
Well I ment configure as in having the right controller card and drive setup to take advantage of the feature.
 
If you have to ask then you don't need it. Spend your time worrying about something else...
 
AFAIK, the 36GB Raptor does not support simple command queuing in firmware.

The 74GB Raptor is supposed to support this feature in firmware, but you have no control over it and which controller you use doesn't matter. According to MS the IBM Deskstars have used simple command queuing for quite some time already.

What the Silicon Image 3512 SATA controller supports is Native command queuing, which can only be supported by native serial ATA drives running on native SATA controllers that support the feature.

The Raptors are not native SATA but rather are internally parallel like every other SATA drive excepting the 7200.7.
 
IBMs have TCQ commands tunneled via ATAPI. It's rather klunky but works good compared to nothing at all. All you need is a driver to handle the logic and dump those commands in the ATAPI packets and you're set. AFAIK the processing of the TCQ on the drive is in firmware. You will see a benefit from TCQ whenever your disk gets hit up in a major way. This can be in a multitasking environment, a multiuser environment, or even a single-process environment where non-contiguous disk I/O is heavy. The old bug in Steam where the disk would thrash for several minutes after startup is a great example of where TCQ can minimize the hit.
 
AFAIK the processing of the TCQ on the drive is in firmware. You will see a benefit from TCQ whenever your disk gets hit up in a major way. This can be in a multitasking environment, a multiuser environment, or even a single-process environment where non-contiguous disk I/O is heavy.

The Raptor 74GB appears to be doing the same thing; it's not controller dependent and is claimed to exist in the shipping firmware.

If it's not controller dependent then it cannot be NCQ, which is a feature that requires support by both the drive and the controller.

Note to other readers:
SCSI TCQ has a much deeper maximum queue depth than either simple command queuing (small queue, IDE) or Native Command Queuing (medium queue, native SATA).
While TCQ may be a term used interchangably for all three varieties, they do not possess the same exact features.
 
Back
Top