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.
The article's authors needed a way to store large amounts of network log data quickly - they're trying to capture packets in real time. For that kind of straightforward use (large volumes of data, only one user, no simultaneous read/writes) it's easy to see why IDE is more cost-effective and speedy, as the article states. However, when you add multiple users trying to write multiple drives simultaneously, the story changes, and the article simply doesn't address that.
What's your damage, Heather?
As if the tens of thousands of times this has been hashed out weren't enough already...
The question of IDE vs. SCSI is not (or should not) be about speed. Really. There are nice, fast drives in each camp. If speed is all that matters to you, go with IDE, it'll be a lot cheaper.
So are there any advantages to SCSI? Sure. But not for the majority of people. SCSI's beauties are:
- You can hook a LOT of drives to one controller
- You can hook most any kind of device to the controller
- You can hook devices up both inside and outside of the case
- You can use much longer cables
- When the controller is waiting on one command, it can issue other commands while it's waiting
SCSI was designed for systems where you would either have many, many devices connected to the controller, or where many different processes (or users) would be accessing the hardware simultaneously - and in either of those situations, it *does* perform better than IDE. However, the portion of systems that will actually enter into that area are very, very few. In general, "if you have to ask, you don't need it."
As for straight speed, if you're looking for all-out throughput, don't rely on a single drive, get a RAID array - be it IDE or SCSI. By getting a faster drive, you can increase your throughput by what - 10%? 20%? A two-drive array will nearly double your throughput, and with quality controllers, it's fairly linear up through three to five drives - again, depending on the quality of the controller.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
The main SCSI advantage is not that it's faster in I/O than IDE (although it used to be). The really big advantage was that (and I think still is), that on a server under heavy memory and processor load, SCSI will outperform IDE because most of the logic is moved off the CPU and onto the SCSI card. So when the CPU is pegged, IDE crawls, but SCSI keeps on chugging.
I think one of the big things is that processor speeds have kept on shooting up, meaning that while IDE has been considered a serious contender for small to mid- sized servers increasingly over the past few years, it's now becoming much more plausible to use it on higher scale systems.
That's probably true. For example, you can buy a n 80GB western digital 7200RPM drive for $150. That is $1.88/GB. The only 7200RPM SCSI drive made these days is the Seagate Barracuda, which is $300 for 36GB: $8.33/GB.
That really isn't the point of SCSI though. I'll accept that IDE wins on a money-per-GB basis. But, IDE has a performance ceiling that SCSI doesn't have. You can't get 10000RPM and 15000RPM drives for IDE at any price, period.
There is a point, when building RAID systems, where SCSI exceeds IDE in the $-per-I/O-per-second metric. In desktop systems, you probably won't exceed this point. But if you intend to have stripe sets of 4 or more disks, SCSI will win the price wars again.
Anyway it really isn't a matter of SCSI being expensive and IDE being cheap. It's the drives that are expensive/cheap and it simply works out that expensive drives get SCSI connections and cheap drives get IDE connections.
P.S. Have fun trying to get you 4-disk IDE RAID all within 18 inches of your IDE controller :)
There is nothing like the metal on metal sound of a high quality SCSI drive. Also you cant find an IDE drive to make the high pitch whine like the 10,000rpm Cheetah. The IDE drives make weak plastic sounds, or almost make no sound at all.
My vote is for the low-CPU usage of scsi devices. My hardrives, DVD drive, CDROM, and CDR are all SCSI.
... start copying around movie files while it does this, and you'll become a SCSI fan real quick.
:| It really does make a difference, though lately IDE has been too cheap to ignore.
I can run three instances of grip and rip/encode from all three drives simultaneously. Desktop still runs like a champ, it doesn't bog down. Rip from one IDE drive and it does ok
Sure, I may pay $400 for an 18GB SCSI drive, but it's worth it.
I wish it were possible to moderate the initial article submission as being off-topic, because from what I have gathered from actually reading this excellent article is that the individual who submitted this story completely overlooked the primary topic on which the article was written...
The speed comparison of SCSI vs. IDE was most certainly referenced within the story context of the story; however, that was by no means the intended takeaway that the author had for his readers - it was but a supporting factoid of his other conclussions and thoughts. The article was a very written analysis, history and summation of the practice of Network Forensics. While it did cover a wide range of technologies (including hard disks) that aid in the collecting of such forensic intelligence, by no means was his observation of the increased speed of IDE drives intended to monopolize the reader's attention or be the central focus!!!
Even worse, the majority of posters have (unsurprisingly) focused on everything but the article's intended subject matter. Now ensues the typical flame-war of people supporting their preferred technology instead of having intelligent discourse concerning this exciting and evolving new field of I/T security...
Oh well...if you can't beat them, I suppose you might as well join them! For the record, my vote remains with the tried and true performance and quality of SCSI...
Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
according to Simson Garfinkel
Hello SCSI my old friend
It's getting very near the end
SpamNet - a spam blocker that really works
That's only true if the program is doing disk I/O asychronously. If your program is doing I/O inline with its execution, it will be paused just as long reguardless of where the disk I/O computation is being done.
personal attacks hurt, especially when deserved
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.
On the surface, I would agree with you. However, the planned usage of the disk space in question becomes an important point.
I had this conversation with Greg Oster, a friend from University, who wrote the NetBSD RAIDframe implementation. We were considering setting up a large network server. After doing some number crunching, something became very very very clear: unless we were going to be moving to Gigabit Ethernet, 3 IDE disks in a RAID configuration were going to be more than sufficient to fill our 100MB LAN.
The point is, whether IDE will be "good enough" depends on what you're using it for. For a large fileserver, IDE RAID may well be good enough, depending on you local LAN. For video editting and other purposes where the data is used on the machine where the disks reside, SCSI's command queueing may be the better choice.
Beta is technically superior to VHS.
Novell Netware is technically superior to Windows NT.
SCSI is technically superior to IDE.
Does any of this matter to most of the market? Not really, since most people look primarily at up-front cost. I've been telling my customers (mainly small businesses) that mirrored IDE drives are the best value for general purpose data storage. The gap has narrowed; IDE definately makes more sense for most people (and even most servers) these days.
If I were specing out a system for high-end video editing, or a system that absoulutely had to process thousands of transactions a second, or a general purpose file or e-mail server that supported thousands of users, or a GIANT SAN, I'd go with SCSI. SCSI shines in really big storage pools, or in places where you absolutely need the fastest possible speed. But for most things, IDE undercuts SCSI by a longshot.
That said, there is one major problem with IDE, and it's not bandwidth (as most "higher-end" IDE-RAID controllers (such as some of the new ones by Adaptec) have multiple channels for multiple drives) - it's lack of VERY standard chipsets & APIs needed to access IDE block devices. The original spec has been hacked onto so many times that you're really at the mercy of the manufacturers' drivers for any "sophisticated" IDE implementations. This has gotten me into trouble several times. SCSI drivers tend to be more plentiful than high-end IDE drivers, and the testing cycles seem to be better because OS vendors actually care about them.
But again, people who buy IDE just on the technical merits of it may as well throw their money away. I wish the situation were different, but I don't think it will change unless drive vendors DRASTICALLY lower SCSI drive prices. Right now they're getting away with charging lots of extra dough simply because managers are hearing "SCSI is way better!" from their employees when purchasing hardware. That may have been true a few years ago, but it'll take a few years for the general consensus to swing in the other direction. (I really, really like SCSI too, and I think IDE sucks as a technology... but money talks) :(
I have a dual P3-850 (was a P2-450). Under heavy CPU load it remains suprisingly responsive. However, if it's under heavy disk load, it crawls, even though Ultra-ATA isn't very heavy on CPU utilisation.
My previous machine was a single PPro-200 with SCSI disks. Under heavy CPU load, it crawled horribly. However, under heavy disk load, it remained much more responsive than my current system.
Therefore I conclude that SCSI really does perform better, even if the drives themselves are matched on throughput and access times. I think most benchmarks suffer a little from tunnel-vision and focus only on the raw disk performance without really taking into consideration what it all means in real world situations.
I put up with the worse overall performance of IDE because it's so much cheaper. Of course, I'm up to my limit (4 devices) and need a new controller if I want to add anymore. And, I have to remember to be careful about tying up the IDE bus attached to my CD-RW when I'm burning discs. I can't see the last point being a problem with SCSI.
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.
IDE drives are fine in a desktop machine. It isn't likely to be heavily stressed and any reads and writes are likely to be from a single application at a time and a single user at a time with a CPU that is typically 99% idle. Such a user doesn't need the benefits of SCSI and the additional costs that the marketing people add.
If however you have 100 people all accessing different pieces of the disk, some reading some writing then IDE will just not cut the mustard. It requires too much CPU involvement. With SCSI the CPU just says here you handle this to the SCSI interface and gets on with something else instead. In addition, with SCSI I can have 15 devices on a single bus, with IDE, I can have 2.
So basically:
SCSI = scalability & heavy loads.
IDE = low cost & single user access.
Use the one appropriate to your application. For most people that'll be IDE, for other people chucking a lot of data around and lots of processes doing different things, SCSI would be better.
Just a quick rant about laptops. People think that a 1GHz laptop is as fast as a 1GHz desktop. It isn't. The laptop disks are designed with power management in mind and are often significantly slower than normal IDE even. So if your managment think that everyone should have laptops, tell them not to complain when their Oracle client runs like shit.
Government of the people, by corporate executives, for corporate profits.
IMHO, the SCSI bus system is better than everything IDE/ATA can offer to date. It's not necessarily the devices that need to be put up against each other. Most recent SCSI disks in "acceptable" sizes are so expensive that you can easily build a RAID system from IDE disks for the same or even lower price. However what's really bad about IDE is the short bus. Face it, length and size do matter in some cases.
You can have a 12m LVD-SCSI bus with 15 devices plus controller running at full speed. But that's not desktop. You'll have trouble just cramming the disks in your average-sized tower, and you still need one or two additional PSUs to get them spinning. And now you take the sucker out for a LAN; but don't forget calling your chiropractor and get a reservation for the next two weeks straight.
Then there's IDE. With todays U-ATA133 specs you're limited to, like, 50cm bus length. Heck, that's about the height of a midi-tower! But it gets the job done. But no external devices for you, sorry. And you're down to 4 devices on your average motherboard, but most users can live with CD-ROM, CD-RW and one or two disks. With onboard RAID controllers coming up, there's an additional four disks possible and you can even plug in a separate DVD drive. You don't need a nuclear plant to get it running, you have lots of storage for a desktop machine and you can still carry it around. Perfect.
To sum it up, I think SCSI is still great, but it's losing on the desktop nowadays. The disks might last longer, it might be more flexible, but in the end, it's way too expensive and overkill. And then there's serial ATA on the horizon.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
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.