Gilbo

Command Queuing W/ 7k250 & Raptor

Recommended Posts

I happened to be looking over the ATA-5 spec last night

The more recent ATA 6 is available, under the project drafts section, at http://www.t13.org/ .... look for d1410r3b ATA/ATAPI - 6 revision 3b.

Hell, for that matter, you might be interested in the most recent ATA 7 .... see the d1532r4 ATA/ATAPI - 7 revision 4 document.

There is a lot of hair in getting this right, and keeping track of which command a given status register read belongs to doesn't get much attention in the spec.

Indeed

Note that I have not read the serial ATA spec yet.

First, you may wish to read, as Hale Landis wrote, about "the specification mess".

- Gilbo's earlier link was to the Intel derivative

- You can find pretty much the same at t13.org under Vol. 3 of d1532r4

Share this post


Link to post
Share on other sites

Seeing as how the

Promise SATA150 TX2+

is the little brother of the S150 TX4 used in the current StorageReview testbed I am going to defer to Eugene on this and say no.

The two cards share the same data sheet on the Promise website. Also the datasheet the makes no mention of its presence. I find most manufacturers mention it if they have it and just leave it out if they don't.

Do well.

Jonathan Guilbault.

Share this post


Link to post
Share on other sites
I am not going to say that it is impossible for a controller to support ATA Command Queuing through drivers (even if it does it is still controller support not OS level as you suggested earlier).

Come on Gilbo - take a side! Either you argue that a controller with specific CQ features is required or you argue that any old controller will do. No pussyfooting around with cover all statements like "even if it does it is still controller support not OS level". :)

There are no controllers that are based on chipsets that lack ATA Command Queuing that perform ATA command queuing.  This suggests to me that the hardware is necessary.
Conjecture.
There is nothing left to say on this subject except that your interpretation of the specification is wrong.
Perhaps it is your interpretation that is erronous?

Don't get me wrong. I agree with almost everything you have written. Where I differ in opinion, however, is that I am willing to leave the door open for the possibility that CQ can be accomplished on a regular, ordinary, everyday controller. But as I stated earlier, the performance of which is likely to be the absolute pits.

Having glanced at the specs, I see nothing that positively rules out the possibilty of this being accomplished i.e. a driver which can interpret the tag in an ordinary controller's registers. Even further, there is room for conjecture that this is indeed the case (See Hale Landis' comment about developing a driver in the thread I linked much earlier).

This pretty much does it for my participation here. Reading through and familiarizing oneself with techincal specification documents, and then extracting the necessary information to shed light on this discussion is about as much fun as having a root canal. Until that time that someone (other then myself) can provide a concrete proof, I'm taking both sides of the fence. That being: I believe that it is theoritically possible to write driver that accomplishes CQ on an ordinary controller, provided the hdd also supports CQ. However, for all practicality (i.e. performance and implementation reasons), I believe that we will only see CQ under the conditions outlined by Gilbo i.e. you need a specific CQ able contoller in the chain.

Share this post


Link to post
Share on other sites

To be clear and not split hairs. You need hardware support.

I don't think a normal controller would bother implementing 32 registers when it only needs 1 normally. Normal ATA read and write commands must be completed before another command can be issued so there is never a need for maintaining Tags or DMA data on a non-TCQ-enabled controller. Any controller that implements these elements obviously possesses specific hardware support for it even if a driver is needed to enable it.

I did mean to say that I didn't think it was impossible. I try and avoid making categorical statements. Never say never.

On the subject of the specification being a pain to interpret I agree with you. If you examine the differences between the legacy DMA read & writes (P.298) relative to the Queued DMA reads and writes everything becomes much clearer. I made myself familiar with that section because apprehension of it is crucial to understanding the difference between queued and normal commands. It certainly makes it much easier to understand things. It also emphasizes the necessity of hardware support, because it makes it clear that normal accesses get sent to the drive one at a time and that, normally, a controller would never need to keep track of 32 potential DMA contexts but only 1. But I said this before...

Do well.

Jonathan Guilbault.

Share this post


Link to post
Share on other sites
The more recent ATA 6 is available

I'm familiar with the mess of ATA specs. I deliberately focus a step or two back in spec versions to get something that is what existent hardware is designed against. In the past the then-current spec hasn't necessarily been the best description of how something on the test bench worked.

Share this post


Link to post
Share on other sites
My claims are backed up in an article on the front page of this website.

Has Eugene ever said why he believes he needs a special controller?

A special controller might come with a TCQ-enabled driver. It that sense a special controller might be useful. But I think it's the driver he needs, not the controller, and the article doesn't explain why he wants a special controller.

Share this post


Link to post
Share on other sites

OK, I spent some time tracking this down. This issue appears to have originated with a note from Hale Landis last year. After exchanging some mail with him and digging into the spec I think I understand the root of the matter.

The problem comes about when there are two devices on one ATA channel. The state diagrams for the read/write DMA queued protocol imply that the device asserts an interrupt to request servicing (when SRV is asserted and nIEN is enabled), which would cause the OS driver to check the status register to see which device needed servicing. Unfortunately, the electrical specification for the INTRQ signal explicitly does not allow a deselected device to assert INTRQ. Since only one device can be selected at a time there will always be a device on a channel with two devices that must be polled.

It turns out that there was/is/might-have-been a controller on that market that dealt with this: the controller had a state machine that could continuously select each device in turn, read the status register, select the other device, read the status register, and so forth, and issue an interrupt to the host whenever either device requested service. This is a highly unusual feature but would indeed be needed if TCQ was to be useful in a scenario with two devices on one channel. The polling is in effect offloaded.

An ambitious driver can try to work around this to an extent. In particular many cases might have highly asymmetric utilization: one device might see substantially more traffic than the other. If the driver issued a command to a device while there was no pending work for the other device the driver might just issue TCQ commands on the assumption that other device will stay idle. If work is scheduled by the OS for the other device then the driver can wait for the command queue to drain and then issue “normal†commands. In this scenario TCQ commands are only issued if it appears likely that only one of the drives will stay selected for a while.

The thing to note, however, is that TCQ should work fine when there is only a single device on a cable, and that this is the usual case. It is certainly the case with the sATA WD Raptor. In this case there is never a need to deselect the drive, and hence interrupts may be relied upon. Eugene does not need a special controller to test TCQ on a Raptor since sATA has only a single device per channel, assuming the Raptor’s TCQ is ATA TCQ.

What Eugene does need is a TCQ-capable device driver. FreeBSD used to have one but it was disabled in Feb-2003 and later removed. Windows has never had one, and a casual Google search turned up no third-party Windows drivers that do it. I know one was written for Linux but I don’t know if it was ever distributed.

The only hope for testing Raptor under Windows with TCQ might be the Pacific Digital RAIDStaQ. I’m not sure what the status of this product is; a BusinessWire article ran on 08/19/2003 announcing it but it is not obvious on their web site. TCQ is prominently mentioned here and implies sATA is (will be?) available.

I think it would be interesting to see how closely Raptor nips at the heels of the 15k SCSI drives in server-scenario testing but such testing is unlikely to be practical with TCQ until WD, or someone else, produces a driver.

Share this post


Link to post
Share on other sites

So there is no driver in Windows, and no driver in FreeBSD. And if there is no driver in FreeBSD there is almost certainly none in NetBSD or OpenBSD. In fact I have a feeling there may be no such driver and may never be. One thing I find is very good rule of thumb, is that if over a relatively long period, something has never happened, it is reasonable to suspect that there is a reason why it has not... Theoretically of course it's great and you may be correct. But you still have yet to reference any information in a manner of any use to me or readers whereby we might confirm your interpretation (which makes it entirely unverifiable). Links or quotes (with verifiable references) are necessary whenever information is referenced. I remain unconvinced, but have nothing more to argue. I also consider it very like you are right...

But then the lack of any drivers in software and the contrasting presence of controllers in hardware have significant weight with me on a practical level. Again, it's not like the standard is new --it dates from ATA-4 I believe. I feel there must be a reason for this discrepancy. And you give me only word of mouth.

Why, by the way, was the driver in FreeBSD removed?

Do well.

Jonathan Guilbault.

Share this post


Link to post
Share on other sites

fangorn# sysctl -a|grep tag

hw.ata.tags: 0

fangorn# uname -a

FreeBSD fangorn.wave.local 4.9-STABLE FreeBSD 4.9-STABLE #0: Wed Jan 21 18:48:35 CST 2004 root@fangorn.wave.local:/usr/obj/usr/src/sys/GENERIC i386

ata tagged queueing support was added to freebsd a long time ago, years ago. what exactly that means, i don't know, but it doesn't appear to be gone.

Share this post


Link to post
Share on other sites

I've been reading through the mailing lists and I have to admit it appears to be enabled purely with software in FreeBSD.

Unfortunately, this means Windows users may have to wait on Microsoft and if Microsoft hasn't done it in all these years then I am pretty sure it is very low on the to-do list. Hardware may be the only practical method in the end. Of course, this means I was technically wrong when I said you needed a controller.

But you do, really, practically... :P I wonder if the code has been ported to Linux.

You'll have to wait for a while for me to sort through the archives though. I'm tired and have a great deal of things to do the next couple of days (Valentine's day, you know ;) , the Biggest Boat show in the Maritimes is in Halifax the next couple days :) ). Good night.

Do well.

Jonathan Guilbault.

Share this post


Link to post
Share on other sites
fangorn# sysctl -a|grep tag

hw.ata.tags: 0

fangorn# uname -a

FreeBSD fangorn.wave.local 4.9-STABLE FreeBSD 4.9-STABLE #0: Wed Jan 21 18:48:35 CST 2004  root@fangorn.wave.local:/usr/obj/usr/src/sys/GENERIC  i386

ata tagged queueing support was added to freebsd a long time ago, years ago.  what exactly that means, i don't know, but it doesn't appear to be gone.

I think it is still there in 4.9 - I see it in the CVSWEB code on freebsd.org. But the code to actually do it is gone in 5.x ata driver sources, even though the sysctl object still exists.

Share this post


Link to post
Share on other sites

Hi guys,

i have Promise fasttrak 150tx2+ pci controller and i can disable tagged queuing i options of my hitachi 7k250 PATA drive. i didnt run benchmarks yet, but there seems to be little difference in random read/write in Sandra (yes, i know, but it was the only SW i could run).

i can post here images of how does the option in win2k looks like if you wanna.

Share this post


Link to post
Share on other sites
Hi guys,

i have Promise fasttrak 150tx2+ pci controller and i can disable tagged queuing i options of my hitachi 7k250 PATA drive. i didnt run benchmarks yet, but there seems to be little difference in random read/write in Sandra (yes, i know, but it was the only SW i could run).

i can post here images of how does the option in win2k looks like if you wanna.

How can you tell that TCQ is being used when enabled? That's the trick - "enabled" is not the same as "being used".

Share this post


Link to post
Share on other sites
Hi guys,

i have Promise fasttrak 150tx2+ pci controller and i can disable tagged queuing i options of my hitachi 7k250 PATA drive. i didnt run benchmarks yet, but there seems to be little difference in random read/write in Sandra (yes, i know, but it was the only SW i could run).

i can post here images of how does the option in win2k looks like if you wanna.

How can you tell that TCQ is being used when enabled? That's the trick - "enabled" is not the same as "being used".

i didnt write that i am using CQ, but that i can enable/disable CQ in options... ;)

the difference in sandra could be because of buggy drivers maybe ?!? <_<

Share this post


Link to post
Share on other sites
Hi guys,

i have Promise fasttrak 150tx2+ pci controller and i can disable tagged queuing i options of my hitachi 7k250 PATA drive. i didnt run benchmarks yet, but there seems to be little difference in random read/write in Sandra (yes, i know, but it was the only SW i could run).

i can post here images of how does the option in win2k looks like if you wanna.

How can you tell that TCQ is being used when enabled? That's the trick - "enabled" is not the same as "being used".

i didnt write that i am using CQ, but that i can enable/disable CQ in options... ;)

the difference in sandra could be because of buggy drivers maybe ?!? <_<

It would be hard to know what to make of any benchmark results unless some difference were seen between TCQ disabled and enabled. Otherwise we'd never know if the TCQ commands were being used.

Share this post


Link to post
Share on other sites
But you still have yet to reference any information in a manner of any use to me or readers whereby we might confirm your interpretation (which makes it entirely unverifiable).  Links or quotes (with verifiable references) are necessary whenever information is referenced.  I remain unconvinced, but have nothing more to argue.  I also consider it very like you are right...

But then the lack of any drivers in software and the contrasting presence of controllers in hardware have significant weight with me on a practical level.  Again, it's not like the standard is new --it dates from ATA-4 I believe.  I feel there must be a reason for this discrepancy.  And you give me only word of mouth.

Why, by the way, was the driver in FreeBSD removed?

First FreeBSD. Look here here in the ad_tagsupported() function. This is 4.9-release. This function requires that the model name of a drive begin with IBM-DPTA or IBM-DTLA or it won’t be accepted.

Interestingly, it also rejects TCQ if an older Promise controller is used? The comment for revision 1.76 (9/19/2000) says here older Promise controllers locked up – I guess they were snooping ATA commands in hardware? No other vendor’s controllers are tested or rejected. This log entry also says Soren did handle the master-slave case and believed he got a 5% performance gain. That’s not what I’d expect but is possible – I wonder what his CPU usage was in this scenario?

FreeBSD 5.2 has all new code and none of this is present. I think the drives above were out of production and supporting the code unprofitable (which may be why nobody else bothered – two drives doesn’t warrant the effort). I’d have to go to Google to get more history detail.

Now for the ATA spec issues. I used ATA-5 r3. This is an argument by negation: there simply isn’t any place in the spec that requires new features in the host adapter for TCQ. If no new functionality is required of the host controller then old functionality in the host controller is sufficient. The bits, signals and state transitions documented are either pre-existing or entirely in the device or host OS driver.

The command description of READ_DMA_QUEUED is in 8.24, WRITE_DMA_QUEUED is in 8.46, and SERVICE is in section 8.36. This is where to start. Every bit and register referenced is in the device.

The DMA queued protocol description is in section 9.9. Be warned this section is not a quick read, and some referenced transitions are to states in diagrams scattered throughout chapter 9. Again the signals referenced are all pre-existing and changes in state transitions all involve the host OS driver and device interactions: no new host controller functionality is referenced (indeed the host controller is barely referenced even indirectly).

Section 5.2.9 has the description of the INTRQ line; the last sentence is critical. Section 9.3 describes the need for "polled interrupts" explicitly; the transitions between states HIO0 and HIO1 are the problem (this is where the host has to constantly select one device then the other so that INTRQ can be driven or SRV seen, which means polled, is the main thing TCQ-capable controllers improve).

If you only have one device then the HIO0<->HIO1 becomes nil (there is no other device to select so HIO1 is never entered and the selected drive is never changed). This means that all of the INTRQ assertions in 9.9 really do happen as expected and TCQ can be done with some efficiency (but perhaps high CPU usage) without a special controller.

Finally, section 5.2 is where the signal interface between device and host controller is located and none of the signal definitions change or are concerned with TCQ.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now