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.
I have two sets of IDE controllers on my system. Each disk I have has its own channel and controller. Because I get to use cheap IDE disks, the cost is much lower than SCSI and the performance is right on par with it. Its not the technology -- its how its applied and used in real life.
--Kevin
IDE may be faster than SCSI in some benchmark tests, but in multiple drive machines where IDE drives share controllers, SCSI will always be faster. Plus, access times and transfer speeds aren't everything. The fact that SCSI supports multiple IO commands at the same time is a major contribitor to the feel of speed.
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?
Toms hardware has a review of Western Digital's new drive, the WD1200JB. 8 megs of cache . The article claims that the drive performs at par or better then Seagate's Barracuda ATA IV. IDE has come along way.
I want one!
A lot of the lower end Sun systems use IDE.
I agree that it's the reliability that's the big factor.
Ever try to add 8 IDE devices to a system? With SCSI it's a snap as long as your power supply is large enough.
I think this is very application specific though.
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.
Like everything else about computing, it all in what you want to do with the machine. SCSI for mission-critical, IDE for everything else. Quite a simply formula; IDE's speed and throughput nowadays is fast/high enough to handle just about anything the usual user can throw at it.
...we are from the government - we are here to help...
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.
Didn't I read somewhere that Google uses IDE drives to host their database? Maybe that or it was archive.org. Companies with such huge investments in the technology have surely done their homework. If you take the cost, reliability, speed, and *availability* of both IDE and SCSI, IDE wins hands down no question.
-kwishot
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.
If all you need is a fast single-user system, or a machine that performs a specialized task, IDE is fine and good. The drives are fast and huge for little money, and the caches are big enough to obfuscate some of the bottlenecks. TiVo uses IDE drives, even - as do most of the specialized NAS servers out there.
If you run a multi-user computer, high-end server, or a system where hardware reliability is at a premium, SCSI is still the way to go, though - but you pay a premium for it. Features like command queueing and disconnect/reconnect are really helpful when running a server that has to manage a heavy load, or a complex multi-user application. And the best RAID systems are still SCSI-based.
But if you are running a server box that runs some sort of brain-damaged inefficient server or client OS, IDE is more than enough for you.
-- Josh Turiel
"2. Do not eat iPod Shuffle."
The point of SCSI is that it allows the disk access and such to be offloaded from the CPU to the processor on the SCSI card. This way your programs don't freeze when heavy disk access occurs.
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.
For CD to CD copy you'd be hard pressed to beat the speed you could get with SCSI. The multiple IO at the same time makes that rock.
As x approaches total apathy I couldn't care less.
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
i think the only thing that matters now is how many drives you need.
ide is now faster, but has been limited to the amount of ide cards/motherboard you have...
granted, with the new abit max boards coming out, with 12 ide devices, that's not a problem...
if you need more than 12 hard drives, when you're building a perfectly NEW system, i would use SCSI... if not, just go with the 'new level' of motherboards coming out, and smack some IDE drives into the case....
now if i could only get a better power supply for all of them.
Runnin' On Empty
IDE vs. SCSI is the big topic here when the authors are talking about how rapid advances in hardware vs. slow advances in bandwidth means it is becoming much more practical for more people to track everything that happens accross the internet.
The ramifications are important.
Also - how does this storage boon impact other kinds of surveillance?
This whole line of thought is a big part of making big brother a reality.
Just a thought.
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
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
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
For the past five years I've run my system exclusively with SCSI components. When I first went out and bought a SCSI controller and a disk I paid a fortune for the privilege. At the time, the UW controller cost me $150 and a 9Gb IBM drive ran me another $300. The controller's SCSI BIOS added another 5 seconds to my boot time, and the IBM drive was full-height and loud as hell on account of it spinning at 10,000rpm. Regardless, I was a happy camper. I had consistently fast disk access, low latency and--best of all--I didn't get those annoying entire-system pauses while waiting for disk accesses to complete!
Over the years the benefit running SCSI decreased. First bus-mastering IDE channels came along and got rid of the annoying pauses. Then they started turning up the clock speeds with UDMA 66, 100, and so forth, until my aging SCSI drives could barely compete with even an average IDE drive.
Naturally, I did what any self-respecting bithead would do: I upgraded my SCSI components. By that time (circa 1999) the price gap between IDE and SCSI had narrowed somewhat (this was before IDE storage prices bottomed out) and I was able to purchase two 18Gb SCSI drives for a mere 25% than the equivalent IDE drives would cost me. And once again, I was happy with decent performance, low latency and high throughput.
Two weeks ago, I found myself scrabbling to free up a few megs and realized it was that time again, time to upgrade my storage. Looking at Pricewatch, I noticed that IDE drives are now cheaper than Big Macs and come in similarly absurdly-sized portions. Would you like 160Gb of space for your MP3s? No problem--they've got you covered, at $200 a pop! Meanwhile, relatively few vendors have stayed on the SCSI bandwagon, demand for SCSI drives is mostly limited to legacy systems that don't support an IDE bus, and a 160Gb SCSI drive will cost you $900.
In the face of this incredible price ratio, I did what any self-respecting bithead would do: I threw in the damn towel. Now I'm in a transitional period where I run 36Gb of fast UW SCSI storage and 160Gb of even faster IDE storage; I have a SCSI DVD-ROM drive, a SCSI CD burner, and an IDE DVD+RW burner, I/O controllers are fighting each other to the death to secure an interrupt, and the inside of my case looks like the aftermath of a tragic explosion at a cabling factory. I'm damned lucky my system is water-cooled, because I doubt any system fan could pull enough air through that morass of ribbon cables to make a difference in cooling.
The moral of the story: SCSI had its glory days, but it just ain't cost-effective anymore. And with Serial ATA looming on the horizon and promising God's own transfer rates, it just doesn't make any sense to buy SCSI.
"In the light of this article does anyone see any reason for going with SCSI in a desktop machine? "
:)
I do a lot of work with 3D Rendering and Digital Video, etc. I have tons of high quality footage that needs to be stored. The reason I'm running SCSI is because its' really easy to add new devices. SCSI has enough channels that you can have one card control a bunch of disks. I have 5 SCSI Drives at work and a couple of Firewire for transporting data around to other computers.
At home I have 1 SCSI and 2 IDE hard disks, and now an external Firewire drive. The SCSI drive is my performance capture drive. I have a 14 gigger that's reasonably fast, and an 80 gigger that's slow. The 80 gigger is for archival of the compressed video, or the uncompressed I don't need to get as quickly. Then I have the Firewire 80 gig drive (also slow) that I attach and do backups to occasionally. The drive stays off when it's not in use. I figure it's more reliable that way.
I can forsee the day coming before too long where I have only high performance IDE drives and Firewire drives, but no more SCSI.
"Derp de derp."
Is that they can have a lot more devices, and it isn't just limited to storage. MY personal system has 5 HD's, 1 cdrom, 1 zip, 1 scanner. All scsi. If it wasn't for that one thing, yea, ide would make scsi people stupid now days.
Not to mention, there is also the smartness of the scsi controller. I've used "good" usb scanners, and ittakes over you computer when scanner. With scsi, you can burn a cd, scan a picture, and play quake3 with out a hickup. Now, who would do all that? Well think enterprises. Think 14 15000 RPM scsi drives in a raid 5 (or what ever). Or think media people having to render imamges while saving to a file and other stuff.
Oh ya, and nothing like sending in an older (3 year old ) scsi drive for RMA, with no questions asks other than "how can I help you".
But I have to admit, these days I keep quesioning myself on my coninuation of buying scsi for home. The I just look at all the things I have in scsi, and think of how I would "try" to do it w/o it. And I can't.
Oh ya, somethign that you ide people can't do
1 10k rpm hd OS
1 10k rpm hd swap/tmp
1 10k rpm hd data
1 10k rpm hd applications/games
1 10k rpm hd mp3/downloads, etc
The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
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
Yes, my reaction was along similar lines: you are going to take some old rock stars' advice on disk systems?!?
Karma: Good (despite my invention of the Karma: sig)
Although many people discuss the superiority of the SCSI protocol vs. the IDE protocol, this is not really the question.
Manufacturers produce the fastest disks on the planet on SCSI interfaces only. There are no 10K/15K RPM IDE discs, period. If one wants the lowest access time available today coupled with respectable transfer rates, one must purchase a 15K RPM drive, which are only available in SCSI interfaces.
For single-user access patterns, the author is correct to state that IDE drives have the lead today. StorageReview.com recently reviewed the latest 7200 RPM Seagate SCSI offering, and it was beaten down in single user tests by half a dozen of the newer IDE drives; however, when tested with server access patterns, it was the clear leader (excluding higher-RPM offerings, of course.) Still, 7200 RPM drives can't beat 15K RPM drives in any access pattern.
And I noticed the author was RAIDing drives -- 3ware's RAID products are very high quality, and their performance exceeds each and every other RAID card out there, SCSI or IDE interface. That surely contributed to his conclusion that current IDE drives are faster than their SCSI counterparts.
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
Isn't this particular article about workstations though? Workstations seldom have more than 2 drives, if even that, and many new motherboards now offer the normal IDE controllers (2 drops each with 2 connections), and a RAID connector (2 drops each with 2 connectors), for instance the Asus A7V333.
Ah yes, another IDE vs SCSI debate. That's my cue to bring up the same point I've made in the last 500 /. IDE vs. SCSI debates, and hope that this time someone actually has an answer.
Heavy use of SCSI drives does not noticably impact system performance. When I say "noticably," I mean those intermittent pauses a computer experiences during disk usage. That is, when you're moving your mouse and the pointer skids across the screen, making it incredibly difficult to get any work done. I absolutely hate this. If anyone knows of an IDE setup that will solve this problem, just THIS problem, I'll dump my ridiculously expensive Seagate X15 in a heartbeat. Until then, its worth it to me to shell out an extra $200/box and deal with smaller capacity drives.
Art Garfunkel - dead or Canadian?
SCSI has parity checking, EIDE (UDMA) has CRC.
SCSI drives (from the same manufacturer) use exactly the same physical mechanism as EIDE ones, but with different controller cards (or sometimes, just different firmware and different physical connector)
SCSI and EIDE do exactly the same ECC mechanism and exactly the same reserved-bad-blocks mechanism.
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.
this would be an interesting discussion... i hope someone comments...
Amazing magic tricks
They do, and I'm writing this at work on one - an Ultra 5.
The IDE drive's performace SUCKS. It's horrible. My PII 266MHz (state of the art at the time I bought it) at home with SCSI drives just kicks the crap out of this thing on file copies, compiles etc.
This was a dark day in Apple history, IMO. :( Apple seems to have done this in an effort to drive down costs, to try and compete better in the low-end PC market. As a result, while you can pick up an SE/30 with a still-functional original hard drive, you don't have to go far to find some iBook user who needed their drive replaced.
Karma: Good (despite my invention of the Karma: sig)
The Barracuda ATA IV is an IDE drive.
IDE still has a long way to go.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
For many years we were told that SCSI is superior to IDE.
This is completely irrelevant unless you have an application which is tremendously hard drive bound, and you've done benchmarking to determine which type of drive or specific model of drive will work best for your purposes. Otherwise this is just the typical, meaningless fretting that some geeks have made a hobby of, such as buying a new, expensive video card so they can get 327fps in Quake instead of 270.
But would you want to put all those disks on the same channel? probably not. In a world where Hard drive keep getting cheaper isn't the ability to put 16 drives on a controller make more sense?
The Kruger Dunning explains most post on
That's just great. I hope that anyone with half a brain who reads this article takes it with an incredibly large grain of salt. If you are using one or two drives, IDE might be comparable to SCSI (as long as your have the drives on separate channels!) for most "workstation" type applications. Any more than that, and SCSI is the way to go (or Fibre Channel...). Here are just a few reasons:
- tagged command queuing (multiple outstanding I/O requests to a single drive)
- disconnect (drive does not "hog the bus" while waiting for an I/O to complete)
- you can have up to 15 drives per channel (compared to 2 on IDE) with minimal performance impact
- 15,000 RPM SCSI drives are available, although they do require extensive cooling.
It really burns me when some idiot claims SCSI is dead just because he doesn't see any reason to use it on his POS desktop system. A friend of mine recently set up a PCI-X based system with 8 SCSI channels and lotsa drives, and benchmarked it at over a gigabyte a second transfer rates (yes, that's 1024+ MB/s). It'll be a long time before you see that with IDE anything.
(Serial-ATA does promise to bring many improvements to the low end of storage, but by the time it gets common, SCSI will be even further along with Ultra320, etc)
---- I made the Kessel Run in under 11 parsecs.
IDE has gotten a lot faster these days but there are still many flaws.
For one, most of the ATA133/ATA100 is a lot of hype. On long transphers (or any transphers that exceed the cache size of the drive) I have yet to see an IDE drive break 30-40 MB/s. In fact, testing an "ATA133" drive on an ATA133 controller vs. an ATA100 controller I saw no gain in speed. There was a gain from ATA66 because the ATA66 bus can't quite sustain 30-40MB/s constant.
Which brings me to another point, like all buses, the 66/100/133 is the peak allowed, it is usually not nearly that fast.
The drive speeds could be higher on IDE. You can get some top notch SCSI drives that run at 15,000 rpm. The best you find with IDE is 7200rpm. The drives would obviously be a little better at filling the bus if they had faster motors.
The IDE bus lacks any intelligence. It is the intelligence you are really paying for on SCSI. The command queues, multitasking bus, ect. ect.
Lastly, SCSI drives are obviously way more expensive, as are there controllers. Of course you are getting a higher quality (read=better built, not faster) product.
Basically what it comes down to in real world performance is no matter what you choise, IDE or SCSI, your disk drives will be the biggest bottleneck in your system by a long shot. If you run a single drive system, or have enough buses so you don't share them SCSI doesn't really provide enough to justify the cost on a desktop in my opinion.
Can someone explain me why SCSI drives are more costly than IDE? I believe (I might be wrong) that many IDE and SCSI drives share the same mechanics and thus, its the electronics that change.
I can understand that 80's and 90's that SCSI electronics were expensive, but I would have expected that electronics prices would fall. How complex is a SCSI controller? Does it have a chip running at 600Mhz or something?!? (Guess not).
Any input about the reasons why SCSI $> IDE is welcomed.
Remember the year 2000? They promised us flying cars. They delivered the PT Cruiser...
Talk about scuzzy! What is it with all these old rock/folk has-beens making comebacks lately, anyway?
What? Simson Garfinkel? Who the hell is that? I thought it said... oh hell, never mind...
"Michael, I did nothing. I did absolutely nothing - and it was everything that I thought it could be."
In addition to the numerous advantages listed by previous posters, SCSI also includes the ability to "disconnect" a drive from the bus, through the software. In theory (or at least in my understanding), then the drive is effectively idle and you can unplug the device from the bus without damaging data on the drive, or corrupting data being sent to other drives.
Of course, those who would try this should be using another great feature of SCSI: the single connector attachment (SCA) plug, which allows SCSI drives to be hotswapped, and often assigned a SCSI ID on the fly.
While many have spoken about the ability for SCSI drives to be used in RAID configurations, a huge benefit is the fact that the drives can be swapped off of the bus/host without turning the host off. This is a huge boon for server environments, where uptime is king. IDE does not have any features like this.
SCSI also has the ability to be used in a "simple" cluster of two machines. Sorry, but I'm hardly an expert on this, so I can't fill in the specifics. But you basically have two identical machines each with a RAID controller, and then these are both hooked up to the same disk array. That way, if one machine goes down, the other still has the current file data.
Earlier. Large batches of early PPC Performas for the education sector went out outfitted with IDE. I have to deal with one such antycomputer from time to time (my significant half's machine) and it is a c*** of s***t. It also has SCSI but the disk and the CD are connected to the IDE bus.
The G3 was the first Mac to have only IDE and no SCSI. Otherwise Apple was quitely putting in IDE for a while before that.
Considering that most Apple cult followers do not check the hardware they had no problem doing this. And the machines still had the SCSI connector on the back for Apple branded external devices.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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) :(
Does anybody have any experience with SCSI adapters for IDE drives. The cost of an IDE drive + SCSI adapter seems lower than a normal SCSI drive.
Nope. That is HVD. LVD is less. 12m if you do not have SE devices on the bus. Even one SE device drops it further down to 1.5m. Check the FAQs on http://www.cablemakers.com. In btw: they are the only ones I found to supply HVD parts.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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.
I haven't seen any IDE controllers that sport a 64-bit/66 MHz PCI bus interface. SCSI already has PCI-X dual-channel U160/U320 controllers. Check out LSI Logic
IDE RAID is fine, it's cheap, but with newer IDE drives pushing 50 MB/sec (sustained) you could max out a standard PCI bus with three drives. Need more throughput? Then you're stuck waiting for PCI-X IDE RAID controllers, or at least 64-bit/66 MHz versions. And in the meantime, SCSI will just get faster.
Mainframe hard disks (historically SCSI) don't use remapped sectors. The drives are built to perfection. They are the top of the line. IDE drives are inferior, because the drives that have imperfections are sold off as IDE. This is because the bad sectors are remapped and hidden from the user.
Same old story people, OS/2 is the quality system but loses, Microsoft is the pile of junk yet sells to the masses. Likewise SCSI drives are the quality niche, IDE drives are the mass-marketed Microsoft-equivalent pile of junk with the bugs and flaws hidden.
While the manufacturing line at Seagate, IBM, Hitachi, Quantum, etc. take their SCSI drives *very* seriously, IDE is more like "yeah it's ok if we screw up a couple of sectors, couple of customers complain so what". The SCSI line failing is like Ford coming last at the Daytona, it's in a completely different league.
The reliability of SCSI drives outclasses that of IDE because the manufacturers discriminate during production (note IBM 120GXP fiasco did *not* affect its SCSI drives). If any cleanroom people can confirm my facts please reply.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
I've been a SCSI bigot since my Amiga days. Just 15 short years ago, all that was really available for consumer-level computers was SCSI, ESDI, and ST-506.
ST-506 was hardly an interface at all. You had to tell the BIOS the number of cylinders, heads, and sectors the drive had (sound familiar?), so that it could do the multiplication and convert logical block addresses into positioning information for the drive. You also had to enter the bad block list by hand, printed on a sticker affixed to the drive. An ST-506 interface was available for the Amiga-2000, and setting it up was predictably a bear.
SCSI saw its first consumer deployment on the Mac, and Amiga got it not too long after. No more CHS crap. No more typing in lists of bad blocks. All that intelligence was on the drive itself. Just plug the drive into the chain, tell the OS what SCSI address it had, and you were ready to start partitioning and using the drive.
So when it comes time for PCs to get intelligent drives, SCSI was the obvious choice. But no, they invent this new thing called IDE. What was different about it? As far as anyone could tell, the cable. You still had to feed CHS addresses at it; SCSI used LBA from the start. IDE drives from different manufacturers wouldn't work together; SCSI mandated interoperability. IDE now let you have two drives in your machine; SCSI already allowed up to seven.
IDE was touted as much cheaper, but it wasn't. SCSI and IDE drive prices were at near parity for years. Manufacturers were offering drives in both IDE and SCSI flavors (all other characteristics identical), with the SCSI flavor costing only ten dollars more (for a $600.00 drive, a typical price in those days, this was epsilon). It's only in the last few years or so that SCSI drive prices have skyrocketed for no readily discernable reason.
Add to that the fact that, even on a modern SCSI controller, all your old drives will still work. I have an old 600M 5-1/4-inch full-height Hewlett/Packard drive with a SCSI-I (asynchronous) interface. I plug it into the Adaptec AHA2940-U2W controller in my main rig, and Linux sees and mounts it just fine. Same with all my other old SCSI drives; I don't have to leave any of my data behind. It Just Works.
I also have an HP Omnibook 800CT laptop, which has SCSI built-in. All my drives work on that, too.
Apart from the artificially inflated costs, SCSI's only real headache is bus termination. But aside from that, the increased speed, flexibility, expandability, and reliability, for me, make SCSI an obvious choice.
Schwab
Editor, A1-AAA AmeriCaptions
I have some recent first hand experience with this one. I built a 980GB RAID out of eight 160GB ATA drives on a 3ware card, and I was all ready to ship it, and but I forgot that we needed to copy 500GB of our data onto it first. That was early yesterday. It is still copying files as I type this. It's pretty bad when it takes several days to copy files onto an array at full bore network speeds, just to fill it halfway up. Never before has network speed/storage space been at such a high ratio before.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
All SCSI drives ship with write caching turned off. This is because they figure if you were willing to pay for a SCSI drive you must value your data.
:-)
All IDE drives ship with write caching turned on. This is because they want to win all the lame benchmarks that people run. Plus, they're mostly used in desktop PCs where you can blame disk corruption on lots of different things.
This difference alone can give a massive advantage to IDE on write-intensive applications, especially on those new WD drives that have 8MB of cache. Of course if the sytem powers off suddenly you could have a problem, but you have a UPS, right? Also, if you run IDE on Windows, just make sure you keep up with the Windows patches for cache problems:
Write Cache on IDE/ATAPI Disks Is Not Flushed on Shut Down (Q153296)
ScanDisk Runs Even Though Windows Shut Down Correctly (Q273017)
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.
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.
3) SCSI allows you more drives - which means you have as much disk space as a slower IDE in 2 SCSI faster drives.
Which is easily aliviated by getting $20 IDE controllers. Hell, my last drive came with its own controler card (due to size)
I mean, just how many drives do you need?
autopr0n is like, down and stuff.
On the speed issue, I don't think this has been addressed... How many IDE I/O cards out there have slots for large amounts of RAM? How well do those caching SCSI controller cards work compared to an un-cached IDE? I dream of a controller card with 1GB of ram on it, and firmware that pre-loads the first 500MB of clusters into RAM (presumably system files and swap.)
Buy a pentium so you can reboot faster.
I was replying to part of the post by beldraen: So what is the point of your post?
information - what was the point of yours?
SCSI as a protocol is far superior (in terms of performance design, connectability, intelligence, and fault tolerance/scalability) than IDE (which essentially acts as a glorified signal converter). Regardless of what any benchmarks attempt "prove," SCSI does not present an overhead which inherently degrades single-user performance. Given the same drive mechanics and comparitive channel rates (ie. 80mb/sec - 160mb/sec LVD, or FC), SCSI disk performance will meet or exceed IDE disk performance, for any given single user application.
When you begin to involve more complex and real-world use of disk drives, the difference becomes tremendous. Think faster disks (15k rpm Seagates), switched fiber interconnects (running >200mb/sec), spindle synchronization, and intelligent command queueing. The added cost (which is usually insignificant compared to the cost of downtime, delayed I/Os, and maintenance) becomes a non-issue.
99% of the high performance computing industry chooses SCSI over IDE as their block device interface, time and time again, and there is a reason. To do so otherwise demonstrates a fundamental misunderstanding of storage interface technology.
A government is a body of people notably ungoverned - AC
Easy! Because corporate I.T. departments think nothing of shelling out huge coin for SCSI arrays. Let's face it, SCSI at home is nearly an impossibility in the face of gargantuan IDE drives for under a dollar a gigabyte. $400 will buy you about 18GB of SCSI storage if you include a controller. You can get about 180GB of IDE storage for the same price. Sure you can't hook up a SCSI scanner or SCSI CDROM to it, but why would you want to? Good USB scanners are everywhere, and IDE CDROMs lack nothing compared to their SCSI bretheren except an inflated cost.
So it has to be the corporations that are footing the SCSI bill and allowing the prices to remain inflated. The drive mechanisms and fabrication plants are IDENTICAL between IDE and SCSI. There is no special razzle-dazzle clean room with neato-keen testing equipment just for SCSI disk platters. It's the same! The only difference is in the electronics, and while SCSI chips cost more than IDE, we're talking the difference between a $10 IDE disk logic board and a $25 SCSI disk logic board, certainly not enough to account for the ridiculous pricing differences of SCSI vs. IDE.
Some have said that IDE is worse off because you can't get it in 10K and 15K RPM variants. To that I say "if you ask for it, they will build it". Your average consumer neither wants nor needs a banshee-screaming, egg-frying 10K or 15K drive. And as we've already seen, about the only thing RPM gets you is reduced rotational latency. It does NOT scale the transfer rate (i.e. a 15K drive's transfer rate is not double that of a 7200RPM drive) with RPM. Do we really care if the drive has a 0.5ms faster seek rate? On a database server, yes. On a desktop, or even a good workstation? No.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
SCSI has one really nice thing going for it...160MB/sec bandwidth. A bunch of drives in a raid 5 configuration can take advantage of Ultra 160's bandwidth, but it's a waste on the desktop since most desktop chipsets do not support 64-bit PCI at 66 MHZ. (Intel's i850 P4 chipset has a bug in it that limits the PCI bus to 90 MB/sec instead of the theoretical 133MB/sec.) If your platform doesn't have the bandwidth capability then there is no reason to spend the dough on lots of fast SCSI drives.
SCSI drives are (for the most part) built better and spin at higher speeds. 10k RPM drives can be had for $350. I have a 36GB 10k Seagate in my box right now. The SCSI drives that I buy come with a 5 yr warranty. You'll never see that kind of warranty on IDE drives. It has nothing to do with IDE vs. SCSI per se....it is all about margin. IDE drives have to be less than $200 to get anyone's attention in the retail space so they have lower build quality.
Most SCSI drives, on the other hand, are designed for higher-end applications where cost is less of a factor. Reliability and uptime are more important (read: servers). These drives cost more and therefore the manufacturer builds (and warranties) them better.
As far as single drive performance goes, the mechanicals of most SCSI drives and IDE drives are pretty similar. That is the limiting factor in a single drive installation...not the bus or the interface.
-ted
Are there 15,000 RPM EIDE drives? I don't think so; the fastest I have seen is 7200 RPM and they are rare. What is the MTBF of the drive? EIDE may be faster at burning out. IBM gives a usage cycle of their drives that indicates they are designed for desktop use, not server use. This is usually reflected in the warrantee periods of the drives. 5 years is standard for SCSI, 2-3 for EIDE.
There's more !/$ on EIDE than SCSI, but the performance and reliability isn't there.
In any case, it's a matter of the appropriate use of technology.
Yet again, Simson shoots his mouth off without knowing the full story. Or maybe he does, and ignored it.
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?
I think people generally get this wrong. THey think IDE is to SCSI as winmodems are to real modems, ie, all processing and hard work done by the cpu.
Not true.
The controller hardware in the case of IDE is on the drive itself. In scsi, there is actually less hardware and logic on the drive itself; those functions are moved to the controller.
The main bottleneck in IDE is the fact that it does not share a bus well. 2 drives on one channel is very hack-ish. SCSI, of course, was designed to be a bus, and to be efficient at what it does.
I'm confused.. you say you have 2 drives, striped, and then talk about copying big files between them? IF they are striped they are one volume, and you can't copy things between them.
I think the only reason IDE is more cpu intensive is because there are some functions, such as copying between drives, that scsi drives can do directly over the scsi bus with very little intervention from the cpu, and with ide, the cpu has to be involved in shuffling the data (or rather, with traditional ide controllers).
Oh yeah. A traditional ide 'controller' is not a controller at all. It's more along the lines of a raw i/o port. It has an i/o address, and a buffered (electrically speaking) set of i/o lines. It's even more 'basic' than your parallel port. I think you used to be able to build an IDE controller with a pair of 8255's.
Certainly they are a bit more complex now, but still, they are a raw i/o port, with no onboard functionality whatsoever.
The ide/scsi argument is still silly. If you want lots of drives working together, use scsi3 or fiberchannel. If you are at home, use IDE simply because it's way cheaper and certainly fast enough for you, especially with all the new funky ide controllers.
And it WAS faster for disk I/O back at the 233 MHz CPU times.
when I built my second PC I planned it to have a 233 MHz AMD CPU, 64 MB of RAM, CD burner and a scanner, all of this running linux. It was one of the best machines money could buy in Brasil at that time.
At that time SCSI made sense, because:
- IDE cd burners used to suck at that time
- SANE only had support to SCSI scanners
So I went shopping and came home with a Soyo motherboard, a K6 233 MHz, a Symbios SCSI card, an Umax scanner, a quantum 3.2 GB HD and an HP SCSI burner. Excelent machine.
Now we have nice things such as USB, Firewire, ultra fast CPUs and excelent IDE chipsets and linux supports all of them, so SCSI doesn't make sense for desktop anymore.
Now I have an IDE burner, IDE HD, USB scanner and USB printer, etc. and all works flawlessly.
SCSI nowadays is for SERVERS. where high the availability of RAID is a question of live and death, where reliable hotswap is neccessary and "details" such as extremelly high noise or subglacial cooling doesn't get into account because the machines will be locked in their own room.
now, if you REALLY want ultra-fast disks in your desktop... firewire is FASTER than SCSI. up to 400 MB/s.
What ? Me, worry ?
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.
Here's the really stupid thing about all this: Although SCSI is hands down a technically superior interface it is not THE standard simply because some marketing bozos thought they should keep IDE along for the ride to better price differentiate the marketplace. I, for one, do not believe that SCSI electronics are much (if any) more expensive to produce than IDE--especially now that modern IDE RAID controllers are getting more sophisticated. There's nothing special about etching silicon for SCSI controllers vs. IDE, that should demand such a disgustingly huge price difference. In fact, the SCSI drives themselves ought to be less expensive than IDE since most of the interface logic is on the host adapter.
If only engineers ruled this world. (-;
"today's IDE drives are significantly faster than SCSI drives".
Fastest ATA drive at the moment transfers up to almost 50MB/s near the begining of the disk, fastest SCSI drive transfers at 60MB/s near the begining.
The SCSI drive has a measured seek time of 3.9mS whereas the ATA drive has only 8.9mS.
Factor in SCSI abilities to be able to queue commands, automatically re-order them and use the bus for more than one thing at a time and you'll see that SCSI is still the fastest. Especially so for IO intensive applications where lots of small transfers are requested.
Whether the price difference is worth it or not for your application is what really matters.
The Western Digital Caviar WD1200JB is one awesome ATA drive though.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Nevertheless, it does seem to be the ugly truth, at least for straightforward read/write tests in a single-user environment.
You essentially have one process doing sequential writes to disk. As almost everybody who has commented intelligently on the difference between SCSI and IDE seems to agree, this is the kind of situation that's going to favor IDE. I'd go as far as to say that it's probably close to IDE's dream application.
No big surprise here, for me.
ON the other hand, 25,000 users trying to POP their mail will probably beat those same IDE drives into submission faster than you can say "thrash the system".
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
When I've bought cutting-edge SCSI equipment, I felt gouged. When I've bought previous generation SCSI equipment, I felt like I was getting what I paid for.
I think that the cutting-edge SCSI drives prices are used to offset the R&D costs. By the time IDE drives reach the same point, the research is already paid for, manufacturing details are already solved, and the company is ready for traditional mass-marketing.
Another factor is reliability. I don't believe that SCSI and IDE drives have the same mechanisms, unless you look at old or crappy SCSI drives and cutting-edge IDE drives. Regardless, you get a longer warrenty with SCSI drives than with IDE drives, and you're probably paying something for that. If the drive mechanisms are indeed the same, I expect that the best mechanisms from a lot end up in SCSI drives, and the rest end up in IDE drives. Just as microproccessor speeds are determined by testing.
-Paul Komarek
...which is why I never have considered SCSI. With disk sizes growing (my 45gb disk was huge, now my 100gb is huge), I can increase capacity all the time (=better capacity), to higher data densities (=faster), more cache (=faster). SCSI would be better at purchase, hands down. But then I'd have to keep the same disk so long, it'd be inferior to the newer IDE drives I would have bought if I'd gone with IDE. I'd rather take a 200$ drive each year than a 600$ drive every three years, it's that simple.
Kjella
Live today, because you never know what tomorrow brings
You need a handle on the distribution--which is probably approximately normal from the Central Limit Theorem--and other parameters. Assuming nrormality, MTBF and variance (or standard deviation) will let you use a chi-squared distribution with n degrees of freedom (where n is the number of drives) to come up with mtbf for the group (again, defining failure as "at least one").
THe statistics get uglier when failure is "at least two":)
hawk
But from everything I've been able to gather, the IDE implementation of TCQ is Broken As Designed compared to SCSI. In a SCSI system, the drive can process commands and then notify the SCSI controller that a command has been completed.
On an IDE system, however, the IDE controller has to poll the disk periodically to see if any commands have been completed. The drive has no way to notify the controller that data is ready and waiting.
It's the difference between a polled and interrupt-driven system. Polling can be fast, if it's very carefully done, but interrupt-driven systems are easy to make fast.
Don't get me wrong, it's a nice improvement to IDE, and it does narrow the gap somewhat, but as its always been, for high-end multitasking stuff SCSI is still the champ.
PHEM - party like it's 1997-2003!
I hunted all over the net looking for benchmarks of SCSI systems versus IDE systems, and couldn't find a damn thing. Sure, people benchmark SCSI hard drives versus IDE hard drives, but nobody ever bothers to benchmark SCSI RAID versus IDE RAID.
I got so sick of it I said what the hell, and ordered up a pair of raid arrays for doing my own tests.
Test system configuration:
Supermicro P4DP6 Mainboard with two Intel Xeon 2.2GHz processors, and 4GB of memory.
Microsoft Windows 2000 Server
No I did not have time to test this under Linux before I had to get these bad boys ready for prouction. I doubt the benchmark results would have been much different, I've seen 3Ware running under Linux at Linuxworld and they kick some serious ass.
IDE setup:
3Ware Escalade 7450 Raid Controller
Three Seagate Barracuda ATA IV Drives (7200RPM 9.5ms access time)
This was set up in a RAID5 configuration.
SCSI Setup:
Mylex AcceleRAID 352 Raid Controller
Three Seagate Cheetah LVD160 Drives (15,000RPM 3.6ms access time)
This was also set up in a RAID5 configuration.
Benchmarking utility used:
HD Tach 2.52
Here's the bottom line I got out of my benchmark tests.
SCSI Performance
CPU Usage: 2.1%, Access time 6.1ms
Read Speed: Max 37.6MB/s Min 11.6MB/s Avg 30.8MB/s
Write Speed: Max 8.5MB/S Min 5.4 MB/s Avg 7.5 MB/s
IDE Performance
CPU Usage: 3.1%, Access time 14.2ms
Read Speed: Max 31.8MB/s Min 4.3 MB/S Avg 18.3MB/s
Write Speed: Max 48.7MB/s Min 12.3MB/s Avg 36.4MB/s
I was a bit shcoked to see the IDE do so well. It annihilated the SCSI in terms of sheer write performance but lagged behind a bit from the read performance. CPU use isn't a factor for most people, who really cares if you lose 1% more of your CPU to the IDE compared to the SCSI.
Those 15,000 RPM drives were loud as jet engines, and they got hot enough that I was thinking of cooking some bacon strips on them. They were too hot to touch. The IDE drives on the other hand were barely audible even with the case off, and remained completely cool to the touch through the whole test without even a fan on them. You tell me which of those two types of drives is going to have a longer MTBF...
I didn't even use high performance IDE drives for that test. I'd also like to point out that the Mylex card was 66MHz/64bit, whereas the 3Ware card was 33MHz/64bit... so the 3Ware card was holding its own even though it was running at a slower rate of speed. I wonder what will happen in future generations of these controllers when they turn up the speed and improve the code...
Cost... I coul have built three of those IDE Raid systems for the price of that one SCSI system.
Space... The IDE drives were 80GB, the SCSI were 36GB. IDE owns SCSI in terms of space. We have some bigass databases where I work so that's actually fairly important to us.
Unless you REALLY need that 6.1ms access time or the extra ~20% in read performance you are far, far better off with an IDE Raid at this point.
The guys at Toms and Anandtech really need to do a major article on this stuff...
For the skeptical, here's a link to the screenshots of the HDTach benchmarks I ran. Be GENTLE guys we do not have tons of bandwidth for this...
IDE vs SCSI
IDE is on the top, SCSI is on the bottom. Interesting how SCSI is fairly linear but IDE is really sloppy and just running all over the place.
Hell is being intelligent in a world full of idiots.
Although single user systems can have multiple processes at any given time, many/most single user apps usually have one process (max) accessing the disk at a time. A UNIX box being used as a dedicated network log would be such an application.
Granted -- a one-line summary doesn't include the source code, but it does indicate the kind of testing methadology they're likely to be using.
(btw: I consider my own box single user (me) even though it has 100% utilization -- I run Seti-at-home. The disk utilization is still single-user in nature (seti rarely accesses the disk)
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
So no. The network is very certainly not the bottleneck.
And on the CPU side, SCSI controllers allow the CPU to sit 95%+ idle while the disks are thrashing their little arses off. I haven't yet seen an IDE interface that good. If you're lucky the CPU will be hit to the tune of 20-50% usage with IDE.
With the 15 devices, who said they were all disks? Oh and the bus runs at 320Mbytes/second.
As I said. SCSI is expensive but designed to scale. IDE is designed to be low cost.
Entirely different purposes, not better/worse.
Government of the people, by corporate executives, for corporate profits.