Slashdot Mirror
IDE, SCSI And Recording Everything
Raju writes: "For many years we were told that SCSI is superior to IDE. I always made my systems with SCSI and the others in the household got el-cheapo IDE disks. In the past SCSI beat IDE hands-down but now according to Simson Garfinkel, "today's IDE drives are significantly faster than SCSI drives". In the article at O'Reilly Network he talks about the tests they had run for storage of network data on disks. In the light of this article does anyone see any reason for going with SCSI in a desktop machine? For servers with heavy disk usage patterns it might be different due to command queuing." Disk types aren't what the article's really about, though -- it's a top-level look at network forensics (including advice on building a traffic-analysis system), and makes some interesting points about the unbalanced growth of storage and bandwidth.
It's about reliability and speed of SCSI.
The advantage SCSI has over IDE is the multiple read, writes on the channel. So a single IDE drive compared to a Single SCSI drive may provide an advantage but you can put several SCSI devices on the same SCSI channel and make use of multiple read/writes. To obtain similar performance with IDE you would have to have a separate channel for every IDE drive. The biggest advantage to SCSI comes with raid. No sure you can get IDE Raid but compared to a good SCSI raid card, IDE raid sucks.
I've noticed a HEAVY taxation imposed upon the CPU during IDE traffic, compared to SCSI.
Sure, transfer rates may be on par with SCSI, but when your IDE drive array starts pulling down huge data files while you are chunking your buddies in Quake3, your framerate is going to feel the pain.
I've not noticed this with SCSI, and it may be different under windows, which i do not run.
Also, SCSI is a more reliable.
Also, factor in the cost of additional controllers. 32 devices per SCSI controller. You want 32 IDE Devices, you will need 8 controllers. I think that sums up the cost difference right there.
That used to be true. But modern IDE controllers are smart as well and take the load off the CPU.
SCSI hard drives have longer life expectancies than ATA drives.
For example, the Seagate Cheetah X15 36LP has MTBF of 1.2 million hours, whereas the Seagate Barracuda ATA IV has an MTBF of 0.6 million hours.
Longer life = better ROI
Phear The Phat Penguin
Yes, the delta between SCSI and EIDE drives performance seems to be shrinking, but I would take a 15k SCSI drive over a 7200RPM 8MB cache EIDE drive any day.
Just my $0.02
The same model plextor CD-RW drive, one IDE, the other SCSI.....
The SCSI drive burned CDs in half the time.
To Do: 1. Take over world 2. Pick up Milk and Bread on the way home
For example, SCSI-2 device types include:
Direct Access Devices (Hard Drives)
Sequential Access Devices (Tape Drives)
Printer Devices
Processor Devices(*)
Write Once Devices (WORM, CD-R)
Optical Memory Devices (CD-RW, MO)
Medium-Changer Devices (Jukeboxes,Tape Libs)
Communications Devices
(*) Yes, you can do processor-processor communications using SCSI. You do, however, need a target-mode driver.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
If you check out Storage reviews File Server Benchmark database, you'll see that the fastest ATA drive scores well below half what a 15,000 rpm Fujitsu drive does.
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
FireWire Faq
Sure USB2.0 is about the same speed as FireWire, but FireWire hasn't been standing still - it's next version calls for speeds of 800Mbps and 1.2Gbps. There's even plans for fiber and wireless based versions.
However, even more import is that FireWire is PEER based. A computer is not required to transfer video from one device to another. There's already a bunch of video equipment that has FireWire support, camcorders as well as the Playstation 2(Sony calls it i.LINK instead of FireWire or IEEE 1394) come to mind.
While it might be possible to hack USB 2.0 for use without a computer, USB 2.0 wasn't designed for it. I suspect such a hack would be a successful as the "patched on security" we see in Windows.
Actually, SSA is rated at 180Mbps, whilst SCSI 3 is 160Mbps. Technically, the fastest drives are RAM drives. DATARAM used to make boxes (8 or 12 U, as I remember) of nothing but static ram. Blazing speed, sky high prices.
OK, I'm nit picking here.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
Actually, this is not completely true anymore. The IDE specification has, since ATA-ATAPI-4, included "Queued feature set" and "Overlapped feature set" which are basically disconnect/reconnect and command-queuing for IDE. However, these are only available for subset of IDE commands (including UDMA-reading and -writing) and for some reason, these features are not available in the drivers used today. There have been some drivers that made use of these features but I do not remember who made them.
FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. Basically the problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives will not only write data to disk out of order, they will sometimes delay some of the blocks indefinitely when under heavy disk loads. A crash or power failure can result in serious filesystem corruption. So our default was changed to be safe. Unfortunately, the result was such a huge loss in performance that we caved in and changed the default back to on after the release.
[...]
There is a new experimental feature for IDE hard drives called hw.ata.tags (you also set this in the bootloader) which allows write caching to be safely turned on. This brings SCSI tagging features to IDE drives. As of this writing only IBM DPTA and DTLA drives support the feature. Warning! These drives apparently have quality control problems and I do not recommend purchasing them at this time.
So, SCSI is better both for performance and for data integrity.
P.S. Have fun trying to get you 4-disk IDE RAID all within 18 inches of your IDE controller.
Not a problem. Last weekend I put together a system with a 3ware 6410 IDE raid card (about $120) and 4 Western Digital 120GB (7200rpm, 8MB cache) drives. Each drive gets its own port on the 3ware card and I had zero problem running the four seperate cables over to my drive bay. Of course I used high-quality teflon coated cables (slide around easily) and I have a "mini-server" cube-shaped case with bays for about 15 drives. But, it really was no problem.
FWIW, this raid can saturate my PCI bus. I used Intel's iometer to determine what stripe-size was best and it turned out that for most work-loads it didn't matter, each stripe-size was able to end-up with more than 110MB/sec of throughput. I wish I had a 4x PCI bus...
Au contraire.
Apple didn't stop using SCSI as standard equipment because of its speed. They used it in their Macs for YEARS because of better speeds than any drives of the time. Apple chose IDE later (when Job returned) for reasons of cost, just as PC makers do. Removing SCSI as standard brought down Mac prices by a few hundred dollars.
For general daily use, and because of recent advances in IDE, there was no advantage to using SCSI as standard any longer for Apple.
However, SCSI, particularly the LVD (SCSI-3) will SMOKE any hard drive interface today, which is why Apple still equips various SCSI configs on build-to-order workstations and their Server models.
FireWire (1394) is theoretically as fast as SCSI-3, but few people can afford a true FireWire drive with genuine FW controllers (earlier FW drives were some IDE or SCSI to FW translator or used slow drives on a FW interface).
Apple is overdue to upgrade their logic boards (motherboards) to the faster buses found in the best PC boards now, so there should be improvements in their performance for that platform in the coming months.
Vos teneo officium eram periculosus ut vos recipero is.
It is fairly rare for SCSI drives to have the same mechanism as IDE drives these days. The only place you find it is low end 7200 RPM SCSI drives, which are a disappearing breed (only Seagate is still introducing new 7200 RPM SCSI models). 10K and 15K RPM drives are on completely different mechanical platforms. In fact, even the media is different, as 10K drives typically have 3" platters and 15K drives 2.5" or 2.6" platters. (Easier to spin them that fast when the platters are smaller.)
Before 7200 RPM SCSI became the low end of the SCSI market, there were many 7200 RPM SCSI disks with different mechanisms than IDE disks. I once had some IBM UltraStar 9LPs; these had a 6.5ms seek time. Even today no IDE disk has a seek time that fast.
If you go back even further the story is much the same -- at any given point in time there are a few low end SCSI models which share mechanisms with high end IDE models, but never any mechanism sharing between high end SCSI and any form of IDE.
Also, SCSI drives typically have better soft and hard error rate specs, which indicates that they do not have exactly the same ECC.
Look at "TCQ" -- Tagged Command Queueing -- that has been worked on by Andre Hedrick in the past, and is currently going into the Linux 2.5.x kernel series due to the work of Jens Axboe.
TCQ is where SCSI gets a lot of its speed, by allowing multiple device commands to be outstanding on the bus at any given time. TCQ really levels the playing field for IDE and SCSI... assuming your IDE driver supports it (most do not).
Just ordered the parts yesterday. It'll be hot swappable (Promise SuperSwap) running NT server with 6 of those 7200 RPM, 120GB special edition caviars (8MB buffer per drive). I'm going to be using a Promise SX6000 (6 channels, one drive per channel) with 128MB memory in a RAID 5 configuration. Sure it slows down to do the parity, but the real bottleneck will be the dual port 10/100 NIC. After overhead, I expect a transfer rate over the wire of roughly 16MB/sec (200Mb - ~72Mb for overhead / 8). It'll be running a Athlon XP 2100+ with 512MB of DDR memory on a Abit KR7A Mobo. All the desktops in the company running WinXP Pro (About 20) will be backing up the entire contents of their drive to it nightly at midnight. I can't wait to run SETI and see if the performance dips when the backups are running. For those curious, case is a Enlight 8950 with 400W PSU, CDROM will connect to the regular IDE1, VGA is ATI AGP XPert 2000 (Inexpensive). I ordered the rackmount kit also.
Grand total was ~$2,800. Ironically, it'll be in the same rackmount as the Compaq ML530 which was purchased before I was hired. Each 36GB drive in that thing cost us $1,200. Times that by 18 or so. You don't even want to know how much they spent on the whole setup with Fibre connection to the server.
I talked to the senior technician at Promise and asked if running the drives in a master/slave configuration on their 2 channel and 4 channel cards would run slower than running one drive per channel when striping. I had always heard that with IDE, only one drive can be accessed at a time. He said that their controllers have a timing for each device so in theory it shouldn't matter, but in tinkering, he noticed a slight improvement when running with one device per channel.
I'd be interested to hear what others have experienceed with IDE RAID controllers versus SCSI RAID contrtollers when it comes down to transfer rate and performance. Do these controllers give the same effect of bogging down of the CPU like IDE desktops because of I/O? Or are they quite similar because of the IDE RAID controller with all the chips on the card?
If you want your IDE hard drive to stop hogging your CPU, then turn on DMA for that drive if your controller and the drive supports it. If they do not, then get drives and controllers which do. If you do not do this, then do not bitch about your hd hogging up the CPU.
SCSI drives may be faster, but once you add other devices onto the SCSI chain, the performance decreases.
For 1/3 the price and a little creativity, you can build a very fast IDE raid array which will compete with the fastest SCSI drives out there.
Reliability? I have some reservations about a platter spinning at 15,000 RPM and how long it can continue to do so.
Firewire is 400Mbps, which is 50 MBps. That's faster than Ultra2 SCSI, but slower than Wide Ultra2, Ultra3 and Ultra160/320 SCSI. Check out this link for details. Firewire is still nice tech, and a fair bit smarter than USB2.0, but it's not the bandwidth king that SCSI is.
Ita erat quando hic adveni.