Slashdot Mirror
ATA133 Controllers Have Arrived
Spot writes "If you're a hardware junkie, then you may already know ATA133 is on it's way to becoming the new standard for drive controllers. LittleWhiteDog has a very detailed look into the Promise Ultra133 TX2 Controller and Maxtor's D740X-6L ATA133 interface drive. " And I just bought a few 100g drives :) I still find it funny that every couple years I buy new hard drives always for around $200... 120 megs, 800 megs, 2.5G, 12G, 30G, 100G. I love this.
But they aren't doing anything to make it SUCK LESS. Drive platters aren't getting faster at the rate the controller is. Very few, if any, drives currently available can saturate an ATA33 bus, sustained. The only thing these ludicrous improvments are doing are increasing performance to and from the drive cache.
Now that IDE has for all intents and purposes killed SCSI on the desktop, you'd think that they'd expend a little fucking engineering effort to make it so that you can control more than two drives on a controller, and so that a other devices on the chain can work while one is processing a command.
I'm horrified at how IDE has flourished. It's the worst possible standard for a drive interface.
Given the current speed of IDE hard drivers - ATA 66 is overkill let alone ATA 133. Hell, ATA 33 is overkill for all but the fastest drives out there. The only benifit you will see, is that the drives onboard RAM-chip cache can be accesses quicker, and that moving from an older IDE spec will get you the new fangled sheiled cables that may help with reliability.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
I'm not going to argue with any of your points, but I still disagree. SCSI is still faster than IDE and most people tend to agree that SCSI components are better engineered. SCSI is a stable standard that is probbaly going to be around for a while. Linux wise, you don't have to bother messing with emulation and the possible IRQ nightmare. I don't see why there won't be a mixture of standards. IDE/ATAPI for joe consumer, SCSI for us discrimating desktop/server buyers, and FC for people who have too much money and like buzzwords.
Has anyone actually benchmarked FC and the latest SCSI drives? I'm curious as to the differences.
there are no stupid questions, but there are a lot of inquisitive idiots
Ultra 100 controllers are typically moving data at less than 1/3 of their rated capacity from almost any modern ATAPI drive. As the article says: In the speed arena, the added bandwidth an ATA133 compatible controller can give you is unfortunately not a selling point at this time. I always get a kick out of people replacing their Ultra 66 controller with an Ultra 100. They are invariably disappointed by the almost identical performance. Now everyone with Ultra 100 controllers can rush out and buy Ultra 133 controllers and experience that same disappointment all over again.
What Ultra 133 buys us is the ability to use drives in excess of 137GB. Suddenly, 160MB drives are showing up that use this new standard. And that's a lot of p0rn!
Now what I want is a drive standard that can support high speed, multiple drives (not just two) per channel, is low cost, and uses a better, more convenient, round cabling system (e.g. fiber, coax, etc.).
-henrik
The patch for UltraATA 133 Support is available here:
http://www.linuxdiskcert.org/
"TK-421, why aren't you at your post?"
The ATA/ATAPI-6 specification has support for command queueing, which is the asynchronous component of SCSI. SCSI also implements out-of-order data transfers within a command, which is not part of the ATA spec, however this doesn't help quite as much as command reordering in the queued world.
In the queued-ATA design, the command phase consists of writing all the same task-file registers as before. However, instead of a data transfer phase, an ATA-6 drive has the option to disconnect from the bus and report a 0x40 status instead of 0x50, indicating it is working on a queued command. At this point in time, up to 31 other commands may be issued while the drive is working on the first command.
Once the drive has the data for any of these commands, it then enables the service request bit, at which point the host is expected to issue the service command. The drive, upon receiving a service command, puts the tag that the drive is servicing into the task file and begins data transfer for that command.
To my knowledge, this is pretty similar to how SCSI drives implement this, the difference being that in ATA land the drive must complete the data transfer for a single command while in SCSI land, the drives can disconnect in the middle of a transfer and resume that transfer later after servicing other commands.
Media rates on most drives are in the 50-70MB/s range, so the other poster saying that it only affects performance out of cache is mostly correct. The only difference here at Maxtor for the 133 vs 100 is basically a few timing changes in our ASIC.
More data, damnit!
first, boot the linux kernel with the IDE-Bus set to 66 (set the idebus=66 option), if your motherboard and drive controller supports it.
ATA/66, Non-CD, has DMA support:
/sbin/hdparm -d1 -X66 -c1 -u1 /dev/hda
Older drives, not ATA/66, but with DMA support:
/sbin/hdparm -d1 -X34 -c1 -u1 /dev/hda
The burner doesn't support DMA:
/sbin/hdparm -d0 -c1 -u1 /dev/hdc
man hdparm for more info.