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.)
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,
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.
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
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
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.
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.
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.
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.
(let me help get you started)
vi? Emacs? What are these things of which you speak?
Ed is the standard text editor!
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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
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