Slashdot Mirror


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.)

20 of 586 comments (clear)

  1. Meaningless.. by grub · · Score: 5, Insightful


    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.

    --
    Trolling is a art,
    1. Re:Meaningless.. by Hoser+McMoose · · Score: 4, Informative

      Sure it's huge, but I could get just as big of a difference between two runs using the EXACT same hard drive.

      The tester didn't even bother to check and see if the files are fragmented, let alone checking to see if the files are on the same part of the disk. The original poster was right, this was NOT in any way a "good" comparison.

      If you actually do want a good comparison, head on over to www.storagereview.com. They have compared many different SCSI and IDE drives and have a VERY good grip as to where and when SCSI's performance advantage comes into play.

      Here's a quick and easy way to do things: Click on "Performance Database" at the top of the page, and then do a head to head comparison of a bunch of few SCSI drives and a few IDE drives. This will give you a whole whack of benchmarks. What you'll find is that on desktop applications, a 7200rpm IDE can almost always outperform a 7200rpm SCSI drive and is usually about on-par with a 10,000rpm SCSI drive. But, as soon as you get into their server benchmarks, the SCSI drives wipe the floor with the IDE drives.

      Then it simply becomes a question of whether you run a server or a desktop. Different drives for different markets.

  2. IDE for end-user... by seriv · · Score: 3, Insightful

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

  3. scsi and laptops by KhanAFur · · Score: 3, Interesting

    This article show that scsi drive have a considerable advantage over the same spindle speed of ide drives. Laptops tend to have slower drives. Has anyone considered using scsi drives in laptops?

    Does anyone know fo laptops that use scsi drives?

    -Mary

  4. Holy shit. by Ophidian+P.+Jones · · Score: 3, Insightful

    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).

    1. Re:Holy shit. by nolife · · Score: 3, Funny

      IMHO, It not too bad but

      [next page]

      he has alot of advertising and

      [next page]

      in some instances I get the impression

      [next page]

      some of this reviews are biased.

      [next page]

      This article brought to you by some advertising dollars.
      Click here for the "best" prices.

      --
      Bad boys rape our young girls but Violet gives willingly.
  5. You get what you pay for. by Sheetrock · · Score: 4, Interesting
    Besides the speed advantage, SCSI drives also typically last two to three times longer than their IDE counterparts, and generally go through more rigorous testing.

    Tape drives are like this, too. They look the same, they act about the same during the write process, but the cheapie drives that come with some servers will fail to reread the tapes if they're reused as constantly as they are in most businesses (who, on average, reuse the same weekly tapes for a full year or more!). Better to put the money into a DLTtape solution than to rely on what's bundled with the server.

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  6. Re:Does it matter? by pstreck · · Score: 4, Insightful

    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.

    --

    Later,
    Phil
  7. FYI: Gerard Beekmans... by Aardpig · · Score: 3, Informative

    ...is the original creator of Linux From Scratch, and therefore registers very high on all standard 7331-meters

    --
    Tubal-Cain smokes the white owl.
  8. And back to reality. by DAldredge · · Score: 3, Insightful

    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?

  9. Re:Real world by Ed+Avis · · Score: 4, Insightful

    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.

    --
    -- Ed Avis ed@membled.com
  10. Oh, come ON. by SlashChick · · Score: 3, Insightful

    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.

  11. pretty outdated hardware... by Malor · · Score: 4, Insightful

    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. :-)

  12. Re:Does it matter? by hayesjaj · · Score: 5, Informative

    Yes, it does matter. The applications that he tested did not include cpu usage, which are assumed to be neglegable. Try doing an IDE Raid setup while your cpu usage is already high (e.g., a cpu and disk intensive game or running many applications in virtual memory). The simple fact that the scsi controller handles the io operations will cause your performance to increase even more than the article suggests. Now, do you need to spend 500+ dollars to store mp3s and your pron? Probably not.

    --
    The world is a comedy to those who think and a tragedy to those who feel.
  13. Holy war? by BenjyD · · Score: 4, Interesting

    What is this? Holy war week on Slashdot? In the last week or so we've had stories on BSD vs Linux, Linux vs Solaris, PHP vs Java, Exchange vs Sendmail , x86 vs PPC and now IDE vs SCSI. All that's missing is Vi vs Emacs and I think we'll have pretty much every major computing disagreement covered.

  14. Explaination of results by darkwiz · · Score: 4, Insightful

    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.

  15. The True Path by Corgha · · Score: 4, Funny

    (let me help get you started)

    vi? Emacs? What are these things of which you speak?

    Ed is the standard text editor!

  16. Re:SCSI vs. IDE: Same experiences by pjrc · · Score: 4, Informative
    Obviously someone has never read the ATA specs... even ATA-2 from the early 90s...

    In IDE, the OS has to position the head, wait x sectors, read a sector, save it into memory, go to the next sector, read again, store again, and so on.

    No. It's NEVER been that way in ATA. Not even the earliest IDE drives. With MFM drives before IDE, and on the Apple ][ and C-64 this sort work was done, but IDE has never been anything like this.

    With ATA (a.k.a. IDE), you write 5 bytes to registers to indicate the starting sector number and the number of sectors you want. Then, you write to the command register to transfer control to the drive and it begins working on your command. All modern systems will (usually) issue the "read multiple" command, which instructs the drive to read many sectors into its buffer and give an interrupt when they are all available in the buffer. This isn't something new. The read multiple command has been in the ATA specs for a long time, and PCs have made use of it since at least the days of Windows95 and Linux kernel 1.0. When the drive has all the sectors in its buffer, it asserts the interrupt pin. The read multiple command comes in PIO and DMA flavor, and if you wrote the DMA version to the command register, a DMA operation happens to transfer all those sectors to whereever you set up the DMA controller to store them.

    SCSI gets most of its advantage from tagged command queuing and disconnection. These features have appeared in the very latest IDE specs, and so far very few ATA drives support them.

  17. ATTN: Slashdot community by fliptout · · Score: 3, Insightful

    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.

    --
    A witty saying proves you are wittier than the next guy.
  18. SCSI over NFS better than Local ATA for me! by MarcQuadra · · Score: 4, Interesting

    I get better real-world performance from my Ultra-2 SCSI drive _over NFS_ than I do for my local ATA/100, and the SCSI disk itself is about 5 years old.

    That says something.

    --
    "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails