SCSI vs. IDE In The Real World

An anonymous reader writes "Gerard Beekmans has a really good comparison of the speeds of IDE and SCSI drives up over on devchannel.org. Should help put an end to the myth of IDE erasing SCSI's speed advantage." Note that Beekmans' test handicaps the SCSI disk a bit, with interesting results. (DevChannel, like Slashdot, is part of OSDN.)

Meaningless..

[grub]

a really good comparison of the speeds of IDE and SCSI drives

Oh please. With all due respect to the submitter and Mr. Beekmans, this "comparison" ignores all sorts of other factors: write caching, command overlap, rotational speeds, et al ad nauseum. Yes, some of these are mentioned but a comparison such as this should have hard numbers in a table not opinions. Not that I'm suprised or upset that SCSI trounces IDE, but his comparison is virtually meaningless.

There are many benchmarking suites out there, I'd suggest these be used for the next test to provide some meaningful results.

IDE for end-user...

[seriv]

and SCSI for servers. It is that simple, it will stay that way because of cost, not because of speed.
-Seriv

Re:Meaningless..

[grub]

Regardless of the things he ignored... 7 minutes to 1.5 minutes is a huge difference

Indeed it is but taking one small test's result and implying that the results can be applied across the board is misleading at best.

Real world

[someguy456]

In the real world, you must also take into consideration different file size ranges, tree structures, and file systems. Comparing two hd technologies while keeping these factors constant isn't very "real world" to me.

Re:Does it matter?

[barc0001]

Negligable? 7 minutes to 28 seconds is negligible? What was the Columbia reentry? Almost great?

And just how exactly does it "all even out" in a RAID setup? IDE RAID and SCSI RAID are still two very different animals...

Holy shit.

[Ophidian P. Jones]

I can't believe this kind of bullshit gets posted on Slashdot. For those who didn't read the article (and I know you're out there), the guy compared how long it takes to open his maildir file in Mutt on SCSI and then IDE.

Since it went faster on his SCSI drive, he concludes that SCSI is faster. Wow! How comprehensive!

If Slashdot keeps this up, I hope they start to get a reputation like Tomshardware.com (those people are full of shit as well).

Re:Does it matter?

[pstreck]

Negligble? Umm, when you can unpack a kernel in a third of the time and see a 6 and a half minute difference in large reads these performance gains are not negligble. If this was a hairline race that was a matter of a few seconds I could understand, but anyone who does work that is disk intensive will benifit from scsi.

And back to reality.

[DAldredge]

And in the REAL real world, the author of this piece discovered that, for his application, the SCSI drive was at least 300% faster.

Why isn't his test, done with real world data, not a 'real world' test?

Re:Real world

[Ed Avis]

In the real world, you must also take into consideration cost. A fair test would be to take a budget of $500 and try two setups, one with IDE and one withSCSI, with any leftover cash spent buying as much RAM as possible. Then see which system perfoms better with a variety of benchmarks.

IDE apologists

[Shaman]

It's funny watching the people who like the cost of IDE trying to make as if this test is totally innacurate.

Well, what if YOUR mail client was taking 7 minutes to go through your mail folder every time? Eh? Not sounding so good now, huh?

Oh, come ON.

[SlashChick]

That "benchmark" was ridiculous. "I have this two-year-old IDE hard drive and I'm going to benchmark it against this SCSI drive. Woop, look! It read my mail directory faster! SCSI must be better!"

Look, I'm not denying that SCSI is faster. But he neglected to even do any other tests! He also neglected to use a newer IDE drive, which hampered the IDE performance dramatically. (Who's going to use a 2MB cache IDE drive in any area where hard drive performance is critical?)

Personally, I'd like to see the test of an IDE RAID array running off a 3Ware card. For the price of one SCSI drive, you can get 3 8MB cache IDE drives, plus the 3Ware card. Oh, sure, it will probably still be a bit slower than SCSI. But at least the benchmarks will show some sort of logical comparison (and the benefit of IDE -- namely, tons of disk space.)

Is it just me, or have the articles posted on Slashdot recently been pretty lame? I just don't understand how some of this stuff gets posted to the front page. This is not a review. This is not a benchmark. It's one guy who tested one application of hard drives and made a conclusion based on that test. This type of stuff can be found in any newsgroup or forum on a daily basis. It should not have been posted to the front page of Slashdot.

pretty outdated hardware...

[Malor]

He tested a 40gb IDE drive versus a 9gb SCSI drive, both 7200 RPM. The SCSI drive was a lot faster, but this isn't any particular shock; this is pretty old hardware.

Basically he just told us that circa 2001, SCSI was faster. I think we mostly knew that already.

It would be a lot more interesting to see the test run with one of the 36gb WD Raptors. They are 10K RPM and are *very* fast drives. I use a pair of them striped as RAID 0 in my main desktop; they're faster than anything I've ever used before, including 10KRPM SCSI. (I haven't used 15KRPM SCSI, which I imagine is probably faster still, but very noisy, which is why I went with the Raptors. )

Note also that IDE drives in general are "tuned for desktop usage patterns". I'm not entirely sure what that entails, but I suspect it involves a lot of read-ahead caching; single-user systems tend to be actively reading only one or two things at a time. SCSI is tuned for server performance, and the test of "read lots of small files" is probably much closer to a "server" load than to a "desktop" load.

What I'd like to see is testing of streaming performance in working with really big files. That's something I do fairly frequently. How fast can you extract, say, a 500MB RAR file back to the same disk? How fast is it if you're reading from one and writing to a second? On a personal basis, I do that a lot more than putting 50,000 files in a directory and then reading every single one of them.

However, if I ever DO plan on putting 50,000 files in a directory and then reading all of them on a frequent basis, I'll be sure to choose SCSI. :-)

Re:Holy shit.

[MrScience]

And, he comes to the conclusion that the drive that's physically faster by 40% and has 2x the buffer is (wow) faster!

Maybe if he compared drives that were closer together, it would be conclusive... but this is pretty pathetic.

Re:Comparo?

[rusty0101]

2.2 Ghz processor with IDE drive outperformed by 750 Mhz processor w/ 3 year old SCSI drive of similar specifications (same size, spindal speed, smaller buffer) by a 7 times margine.

Note also that the IDE drive was used exclusively for this test at the time of the test, and the SCSI drive was in a server which was active doing other things as well.

I would think that the 50,000 message folder would be of a wide variety of file sizes. Though it would be really easy to create such a folder of all one file size, simply by running a script that creates that many simple message files with the word "hello" in the subject and the body. As a developer for "Linux from scratch" I would suspect however that this is his message archive, which is likely to contain anything from a "this package sux" message on up to messages carrying a significant portion of the source code to Linux.

As to your comparison of a .22 and an RPG, I would think that a more appropriate comparison would be a .44 automag to a .22 revolver. The .22 is less likely to bother the neighbors. The .44 automag is more likely to stop the rampaging bull. Which is more appropriate for use will depend upon the use.

For my own needs an IDE drive works well. Then again I don't build and install a new Linux kernel every couple of days either.

Obviously your milage may vary.

-Rusty

Explaination of results

[darkwiz]

One would expect the SCSI drives to consistently wallop similarly configured IDE drives (same buffer, spindle, size, #heads and every other physical characteristic you can think of) based solely on one observation: Tagged Command Queuing.

TCQ allows a drive to execute commands out of order to optimize the access pattern. This can have a HUGE impact on performance. Relatively few drives support TCQ on ATA, and very few chipsets support it as well. This is mostly because people who buy ATA aren't *real* performance freaks. They want high streaming performance (like hdparm -tT), but don't know to care about random access performance as it may not be relevant to them.

Server/database access patterns are far more random than typical desktop usage, and this is where SCSI wipes the floor with ATA.

Some have pointed out that RAID enclosures are moving towards IDE drives. This is due to the fact that the integrators are using optimizing logic in the controller to handle emulating TCQ. So you can have a stone-dumb drive in there and it doesn't matter as long as the physicals are there.

SCSI drives also typically come with caching algorithms which are intended to try to increase cache hits by using more intelligent cache allocation and predictive reading.

Combine that with better, more intelligent controllers, command detachment, and infinitely better bus sharing - and SCSI cannot be compared to ATA in high demand situations.

Re:Meaningless..

[gladbach]

I was thinking the same thing... those raptors are supposed to scream... BUT, they arent exactly the old breed of ATA drives anymore.

the lack of cpu usage needed is still what cuts it for me w/ scsi. IDE may be as fast, etc, but on a high load, real time performance server, SCSI is a must, any way you cut it.

Re:You get what you pay for.

[Naeleros]

Like anecdotal evidence?

I have owned 10 wintel PC's in the last 8 years (I usually sell systems when I upgrade.. but, still have a few of them). Never had a hard drive failure.

I work for two places and have probably seen 50+ wintel PC (desktops) move through in the last couple years (including the new ones we purchased this year). Never had a hard drive failure.

At one place we have 6 Mac's (2 brand new). We've had 1 hard drive failure.

What does it mean?

Not a damn thing. Its totally anecdotal and worthless 'evidence' of anything.


p.s. One of the easiest sells in marketing.. is that if something costs more.. it must be 'better'. Ask a salesman sometime ... particularly computer or used car...LOL

Re:This is not a review

[Cynikal]

of course its not a real review/benchmark.. look at the reasons for the test.. he plainly states:
"before my wife would allow me to"...

the whole point of the testing was to convince his wife to let him buy one.. and she most likely was asleep at "integrated IDE controllers".. apon waking up, all he had to say was "From my testing I concluded that SCSI being faster than IDE is not a myth. It is very much a reality." and obviously got the go ahead

remember, in the immortal of homer simpson "facts, schmacts... facts can be used to prove anything that is even remotely true"

ATTN: Slashdot community

[fliptout]

As this "article" painfully demonstrates, we need the ability to moderate things on the front page.

If the editors cannot distinguish what is trash or what isn't, let the community decide.

Thank you.

Re:Holy shit.

[G00F]

Maybe some day they will test a nice 15000RPM SCSI drive against a nice 15000RPM IDE drive. Then we'll really know what's fastest!

You mean testing a 10 year old 15k rpm SCSI drive vs a brand new 15k rpm IDE drive?

Re:SCSI vs. IDE: Same experiences

[ergo98]

The SCSI cd-rom was a quad, and the IDE a 6X. It took 30 seconds to load a level on the 6X IDE system and 4 seconds to load on the quad SCSI system...

You see, here's the problem with armchair benchmarkers, such as the site linked by Slashdot, and your, er, benchmark - You do realize, of course, that a 6x CDROM has a throughput of a blistering 1MB/second, right? That even on traditional IDE the controller subsystem sat around waiting for data about 97% of the time? The idea that there is any measureable difference between interfaces at such an absurdly low throughput, even accounting for massive interrupt overhead (such that classic IDE had, but modern IDE doesn't) would be just a blip on the radar. Your methodology is crap, and the more likely explanation is that the IDE drive had a physical problem such as overspeed or a focusing issue.

The ONLY advantage IDE has is price. End of story.

Wow, I guess we might as well wrap this whole discussion up right now!

Check out storagereview.com

[spinkham]

Check out storagereview.com
Great drive reviews, the best out there..
At the moment, the best scsi drive has about a 2x lead over the best IDE drive in "Server style" loads, and about a 20% lead in desktop type loads.

Note that this really isn't an interface issue, but a market issue. With tagged command queuing in serial ATA, one of the main reasons for SCSI's dominance is gone. Unfortunatly, no enterprise class drives support it yet.

The difference between SATA and SCSI is market.
The fastest SATA drive goes for $160, while the fastest SCSI for about $700.

SCSI drives are manufactured for the "no compromise" audience, and are therefore traditionally faster and more reliable.
SATA puts IDE drives in the same interface class as SCSI, and more "enterprise class" drives are starting to be built with that interface.

Given a well-built SATA drive that includes all the SATA features like TCQ and drive with the same build quality in SCSI, I bet that the difference would be minimal. There are no comparable products at the moment though, so time will tell..

Bad Science begets Meaningless..

[MrChuck]

SCSI *is* faster by a good bit than IDE (and SATA is the same interface, really, just fewer wires with fast serializers at each end)

However, the test is about as bogus and incomplete as the 2.6.0 vs. 2.4.x vs *BSD tests earlier this week.

Old, crufty files on IDE, all over.
Good test would move the files to an empty, freshly formatted IDE drive.
And to an empty SCSI drive (he did just the latter).
And SCSI will be faster and the test will be better.

I have mail scattered across a crufty barracuda. It was NOTABLY faster when I tarred it up to move it to a fresh disk for /home. The exact SAME disk (but without 2 other partitions on it).
So all my files were together and contiguous and on the outer sectors.

RE: Note that the controller is an Ultra160 and is a 64-bit card put into 32-bit PCI slot. The drive itself is an Ultra320. The speed increase would be higher if I were to purchase an Ultra320 controller with a motherboard that supports 64-bit PCI slots.

'scuse me while I wipe up the milk I just blew out my nose.

Yes, in theory this would be faster in a 64 bit slot. And you will run at full speed until that cache is empty (think gazillionth of a second). You would gain if the bottleneck were that pesky 32bit PCI slot. But its not. After the cache burst is done, you are limited by the disk speed. And a 5400 RPM disk will not put out more than 8-10MB/s in real use (dd is NOT real use).

I *do* use Ultra160 SCSI on RAID boxes that contain 15-20 15000 RPM disks and several hundred MB of battery backed read and write cache. And we get a (real world) 80-100MB/s throughput (again, dd(1) is not real world).

It's a pity, because doing these tests CORRECTLY would have been worth while. And coming from ! Tom's Hardware, (just which manufacturers are funding them?) is a good thing. But this is bad science.