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.
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.
Multiple drives on one channel.
Zeshan
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.).
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!
You can get information on Serial ATA at serialata.org. You will find that these new ATA controllers break the 4 drive limitation, and have a very small cable, as opposed to the air-flow-blocking current ATA cables.
Another mini-rant I have to get out of the way, is about the psychotic SCSI user blaming ATA for keeping SCSI from becoming a real force in desktop computing.
Guess what, if the SCSI manufacturers would have brought the price down to reasonable levels, this would not have happened. Is SCSI better? In servers, heck yes. On the desktop? No, not really. Even on small servers, the advantages do not outweigh the extra cost of SCSI. The folks in the SCSI industry made a concious decision to stay in the server. Price DOES matter on desktops, and there is NO technology that can beat ATA for price/performance. Thats what ATA is for. Bleating that its' "technically inferior to SCSI" is stupid. They are not intened to do the same things. SCSI=Server Fibre Channel=Server ATA/Serial ATA=Desktop
Whoops.. let me fix that link:
http://www.linuxdiskcert.org/
Sorry about that.
"TK-421, why aren't you at your post?"
I can answer two of your questions.....
With new processors, how much are you REALLY giving up in processor useage? This was only a problem on Pentium and 486 processors.
On the Fibre Channel front, FC is used for external disks. FC has a maximum distance of, someone correct me if I misremember, 2 kilometers, on optical fiber. The controllers are very expensive. The drives are expensive. The entire point of FC was to get over the 15 drive limit of SCSI and to get over the distance limitations of SCSI (3 meters) and Diff. SCSI (15 meters).
I am not aware of any internal FC implementations on standard server hardware, but as a rule, its an external JBOD application.
IDE is fine as long as the drives are within 30 inches of the controllers, not very practical for servers.
As for fibre channel, it is a physical layer (in fact more than one physical layer) and a transport layer, but guess what runs over the top of that - SCSI!
Parallel SCSI is in it's last days, and I wouldn't bother with it on a PC except to get very fast (10k or 15K) drives, but SCSI lives on in other forms, it even runs over IDE as ATAPI.
Check out storagereview's latest review of 20 drives. Given 10,000 i/o operations per second, all SCSI drives used ~20 percent CPU, while all IDE drives used ~40 percent CPU. The CPU was an Intel Pentium 4 2GHz.
I've heard this quote for almost 10 years. SCSI is quite alive and kicking. Ultra-320 and Ultra-640, that's 320 MB/s per channel. Two channels per card....
Serial SCSI is coming, and will bring more compatability with Serial ATA, but there will always be a market for SCSI, because the commodity market will just never be fast enough. Workstations and Servers have a hard time living with the huge performance impacts of IDE.
Serial ATA though will be much hotter, and still doesn't fix the limitations in the OS regarding ATA threading, doesn't add disconnects, and wastes more bandwidth, 150MB/s when a normal ATA drive will if you are lucky give you 30MB/s.
While cabling is better, and it will allow hotswapped sATA drives, it is still just a bit faster SCSI.
You do have a good point about price. Disk drives and controllers are more expensive for a reason, better performance, reliability, and infrastructure. You get what you pay for in I/O storage. Too many people skimp on this.
Most PCs still have only 32/33MHz busses. SCSI blows the doors off of this, and most systems can't even handle this.
Which of course, brings us to the other point. ATA-133 would exceed this PCI bus anyway. So, even if you could get close to theoretical, anything faster doesn't make sense for ATA.
I couldn't agree more.
No drive in existence can even come close to saturating ATA/66. Under some conditions they break through 33MB/s, but that's about it. ATA/100 and ATA/133 then are totally useless. But let's make a few calculations:
ATA/133 interface can transfer data from the HD's cache to memory at 133 MB/s, while ATA/66 drive can do so at 66 MB/s. The standard cache size on modern HDs is 2MB. At 66MB/s it takes 0.03 seconds to read the entire cache. At 133MB/s, it takes 0.015 seconds. Therefore, whenever you try to read data from disk, an ATA/66 drive will operate at 66MB/s for the first 0.03 seconds! After that, the speed will be limited by the speed of the spindles. Similarly, an ATA/133 drive will operate at 133MB/s for the first 0.015 seconds. Also, an ATA/133 drive will be faster than ATA/66 drive for a whopping 0.015 seconds at a time! Wow!!! (and that's assuming that the desired data is in the cache in the first place...)
How about improving IDE so that multiple drives can operate concurrently? That would justify the interface speed increase. How about making it hot-swappable? How about making it usable for external devices? But no, they have to keep on making ATA/100, ATA/133, ATA/999, ATA/2000, etc. so that Joe Consumer has yet another marketing gimmick to buy...
___
If you think big enough, you'll never have to do it.
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.
If you want hotswap you have to get a controller that supports it. 3ware has the Escalade IDE RAID boards that support hot swap. Some people have said that 3ware is no longer going to be selling these boards but I think 3ware is merely idiotic by not including the details they used to on their product page. You can buy there controllers at a number of places including: http://www.hypermicro.com/store/index.htm
See StorageReview.com for more information. Adaptec's IDE RAID board probably supports hotswap too but it is a bit more pricey. If 3ware continues to be idiotic Adaptec might be a better choice...
64 bit PCI slots have been around for while, and are common in servers. Theyre around twice as long as a 32 bit PCI (duh), and older 32 bit PCI cards work fine in them.
I just got a SX6000 and I am testing it a bit because I want to put some drives on it and make a RAID 5 disk. I've known people having problems with Promise controllers dropping disks in the RAID, so I have installed 2 Western Digital 80GB and striped them. That way I figure if it's not stable, I am sure to know about it. :)
:-)
:-)
:-) )
When I am done testing it, I'd really like to install FreeBSD on it, but sadly there's not yet any drivers for it. Read on Google that Mark Smith is willing to do a driver for it if he gets the hardware and if I could, I'd be more that happy to send a sample.
Anyway the driver status was that W2K was easy to install with the driver disk, but once that was tried, I installed RedHat 7.1 because there was drivers for it. and it seemed to work, execpt for for the extensive many hours it took for the drivers check that the RAID was clean with no partitions.
I then discovered that if I choose "other" as operating system in the bios, RedHat 7.2 install could see it as a i2o controller. Mandrake installed failed for me. But I am also a "new" Linux user since FreeBSD has been my preferred choice but since it does not support it, I install Linux instead.
So before you go ahead, make sure that there's drivers for your os.
The SX6000 is a nice "low end" RAID, but it lacks the features of the "real" ones such as adding another disk to a existing RAID. I was not able to do that from the BIOS or the Windooze Utility(which is not available from Linux, and I don't think that it works from Wine
Hope you could use my input.
Uhm next weekend I'll get a few more disks and try a RAID 5 setup. And I really like to see how it reacts on different size disks when the time comes where one drive fails and you can't the just that model that anymore. But still if it won't drop the drives on me, I think it a great controller considered the price..
CU
One reason, which others have hit on, is that it's nothing more than an ego-match with SCSI's 160 MB/sec bus speed. However, there is a semi-valid reason: The spec includes a addressing extension which increases the maximum size of a drive into the petabyte range.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Dude, FC is SCSI. Take a look at the SCSI-3 spec sometime.
The CPU overhead argument has been a myth for a while and was put to rest for good when the ATA-66 spec was released.
A very long time ago, IDE controllers didn't support DMA, so a disk I/O operation would tie up the CPU for shuttling data between the PCI bus and memory. But controllers that support PCI bus mastering and DMA have been around for years now. The biggest problem was that MS disabled it in Win 9X by default and a lot of average users didn't know enough to enable it. Nowadays, both IDE and SCSI controllers control the PCI bus on their own and transfer data directly to memory via DMA, only generating one interrupt when the operation is complete.
Until a couple years ago, SCSI also had another advantage. SCSI controllers can accept multiple I/O commands, queue them up, and asynchronously execute them in optimal order. IDE controllers used to be able to process only one I/O operation at a time. But as of the ATA-66 spec, IDE controllers now support the same command queuing/tagging features as SCSI.
The only real advantages that SCSI has left are support of many drives per channel and much more generous cable length limits. The fact that the fastest drives are only offered in SCSI version is purely an artificial construct of the market.