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.)
I don't want to install an extra SCSI board for some negligble performance gains.
In a RAID setup, it all evens out anyway.
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,
Why didn't he test one with 8 megs? Or ones of rougly the same size? Or ones with roughly the same anything? He also could've tested a newer Serial ATA drive. Heck, for the price of SCSI, you can build a nice RAID with multiple IDE drives and win back lots of speed. This review is a very big mess.
and SCSI for servers. It is that simple, it will stay that way because of cost, not because of speed.
-Seriv
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
Funny, I had the same experiences with older hardware: SCSI always appeared to be faster, subjectively, on a medium load database/web server. I was really impressed about the dimensions (7 to 20 times!); the pure hardware capacity/speed gave no hint.
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.
Robert Bindler
A Computer Science student's views on technology.
No real benchmarks and how can you have a drive test with no pretty graphs?
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).
Not that I don't believe SCSI isn't faster than IDE, but why did they take what are notoriously the slowest IDE drives out there (Western Digital)?
It seems to me that they set out to prove a point from the start. If it was me, I would have used a Seagate IDE drive.
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.
The document lists one and only one case. I don't doubt that SCSI has performance benfits that is pretty well known. I've always wondered why they don't upgrade IDE with a better command set much like SCSI, well they haven't they just increase the clock speed and offer better buffering. So there is a valid case for a comparison between SCSI and IDE. This review does one and only one test which proves that SCSI wins on one test this is not a good article. He reads one and only one file. The real question is how well IDE and SCSI operate under real multi-treaded OS conditions. Slashdot editors should be rejecting this article in favour of one with a real indepth analysis. SCSI will win but not for the reasons listed in this article.
...I want Fibre Channel, baby!!! Amateurs. ;-)
Javascript + Nintendo DSi = DSiCade
That was the lamest thing I've ever read from /. Where are the numbers? Graphs? Not to mention- 800 dollars! Granted, its Canuck bucks, but still... Sheesh. Does the average bear need that time difference?
.22 and it didn't move. I shot it with a bazooka and it blew up. Therefore- bazookas are more useful than .22s. Which may be true in certian situations. But if I'm plinking in my backyard I'll spend the .07 cents that each 22 round costs me rather than hundreds on that RPG round. I dont need an 800 dollar hard drive to frag in UT, check my mail, surf the net, or read /.
Now- rewrite this article... Explain the systems it was used in. He mentions that the IDE system had a faster processor. What was it? How much faster? What kind of motherboard? I know from experience that a crappy-ass IDE controller can handicap you from the start. Whats the difference if he used a dedicated but cheap IDE controller card? This seems on the level of- I shot a pumpkin with a
No one expects the Spanish Inquisition!
How long does it take to read my 50,000 message maildir.
:-)
Well that's scientific.
Not to mention, it's an archaic 2 MB cache drive. Yeesh.
I think IDE versus SCSI is a fairly silly comparison these days. They each have their use cases. For lowest seek times and max IOPS, go with a 15K SCSI drive. For fastest transfer rates, do RAID with IDE drives. Hell, the Xserve RAID I work with daily can transfer about 350 MB/sec sustained. Try matching that with SCSI drives
...is the original creator of Linux From Scratch, and therefore registers very high on all standard 7331-meters
Tubal-Cain smokes the white owl.
[root@localhost root]# hdparm -t /dev/hda /dev/hda:
Timing buffered disk reads: 146 MB in 3.02 seconds = 48.34 MB/sec
This is IDE 7200 60Gb Maxtor drive using Linux 2.4.22-10mdk
A quick trip to www.pricewatch.com clearly shows why IDE and Serial ATA are winning. The SCSI drives come in smaller sizes at more than 2x the cost of the other drives. They also don't require you to buy a SCSI motherboard or an extra card to use.
Perhaps he should take a class on statistics or research.
Why doesn't he compare it to a newer serial ATA drive running raid 0.... Since everyone has newer boards anyways, I dont have one myself or I'd bench it but I am sure its a lot faster than what his ide drives are getting, prolly not as fast as the scsi but I bet a lot more in tune, and will leave you with a pocket full of cash.
Oh and did I mention to even use U160 you need either a kick butt motherboard or a $500 SCSI card?
Even most RAID enclosure vendors are going to IDE drives.
This is a test. This is a test of the emergency sig system. This has been only a test.
And compare serial drives to serial drives.
I would have loved to see that SCSI against an SATA150 drive.
Looking for hardware (Currently need: Large Etch-a-Sketch) Have one? See my journal!
In my experience, IDE is nothing but a mess. For example, I had removed power to an IDE drive in my machine, but left the IDE cable connected. The result was a machine that simply didn't want to boot.
Another big problem with IDE is that it's limited on the number of devices it supports without purchasing seperate IDE controllers that use up PCI slots. SCSI is much better on this.
On the other hand, I will be very curious about the performance of SATA, which is somewhat based off IDE, but with significant performance improvements. The future is still based off IDE because SCSI hardware is just too expensive to go in most machines. At a time when cost is a bigger factor in hardware than performance, SCSI just won't win.
Help me. I've been modbombed by a few people with entirely too much time on their hands.
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?
I seem to recall comments on Slashdot about how long it takes to copy files on Macs or something.
Just as a curiousity, I wonder what sort of controller he was using for the IDE. Judging from spindle speed alone means little especially due to his cramming a 64 bit card in a 32 bit slot would lead one to believe that he might also have the '1 year old drive' on a 3 year old motherboard with a non U66/100/133. Not enough specs to be touted as any sort of real world comparison. Real world tests do show the U320 SCSI standard as being the fastest out there but I'll take my crappy 3ware U/100 8 port RAID card with 8 WD 200G 8M over a similar SCSI just because its under 1/3 the total cost.
The Maxtor was 40gb
The Atlas was 9gb
The Atlas obviously had less tracks too seek through than the Maxtor because it had 1/4 of the total number of tracks the maxtor did. This would totally account for the 1/3 speed increase seen over the IDE solution.
Also to take into consideration is how much buffer each drive has. If I remember right, Atlas's have like 8 megs of buffer, while the 40 gig maxtors have like 2.
It appears that DevChannel, a part of OSDN, adheres to the /. article format: 500 words or less.
Great comparison? He only tried 2 things! What about random file access? large/small file access? streaming/random? multiple streaming? I don't pretend to know all aspects of Hard drive performance, but it's sure as hell bigger than that article supports. What a waste of bandwidth.
At least they got Gb and GB correct. ;)
Anyways, it seems that network performance has always been more of a bottleneck than hard drive performance. Is it the other way around then for many other admins???
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
I can't believe how short sighted and obtuse this articles is. But you know what really burns my ass? A flame about this /points at buttocks/ high!
--
It eliminates the all those other variables, leaving only the drives themselves to affect the speed. Of course, whether or not reading a mutt mail folder really depends on drive speed is up to you.
Facts do not cease to exist because they are ignored. - Aldous Huxley
Even something such as that could have a *huge* impact on speed.
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?
...Steve
In the "real world" speed isnt the only important factor, if it was will would all use solid state drives.
~$150 for 40GB IDE setup
$700 for 9GB SCSI setup
You could have the 3 or 4 IDE drives running in a raid1 setup which would improve read time, have better data security and you would still have 4 times the capacity of the SCSI setup of the same price.
SCSI is for dumb rich people, and people who assume you get what you pay for.
He's comparing different priced setups. An IDE RAID setup of equal cost and capacity to the SCSI would probably have faired much better in the benchmark.
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.
Simpli - Your source for San Jose dedicated servers and colocation!
I smoke cigars, and feel just fine.
My coworker eats life-savers, and has been diagnosed with skin cancer.
I conclude from this experiment that life savers cause cancer, but cigars are ok.
Conformity is the jailer of freedom and enemy of growth. -JFK
However, in the real world, if you were to start shoving SCSI drives into laptops you would have to carry a few extra batteries to get the same amount of running time as someone that is using a standard equipped laptop. Plus, the cost would be outrageous.
Modern Laptop hard drives are actually much swifter then laptop hard drives of 5 years ago and even 3 years back. Not by much mind you, but they are a little bit faster...
Specifically: What was the file-system used on each system? What size clusters were used? The SCSI platter of 9GB (compared to the 40GB of the IDE) has a significantly simpler job of locating the data if it has not been defragmented. What's with the 4MB cache on the SCSI vs. 2MB on the IDE? Why not do the comparison on different operating systems? I'd like to know the manufacturer of the motherboard and the production date? Lastly, as a responsible service to those less knowledgable -- it would have been nice to see some mention that IDE disk-striping can be had for less than a standalone SCSI drive+Controller.
-- I'd give my right arm to be ambidextrous
Single user, single machine, single disk, single transaction? IDE performs ~equal to SCSI, and at a fraction the price.
Multiple simultaneous transactions is where SCSI wins. Try comparing SCSI vs. IDE for something like an NFS server, and watch SCSI leave IDE in the dust.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
No no, HERE is a sexy display... Someone sent me a link to this today.
MUST...HAVE
I would just like to take this moment to give mad props to Gerard Beekmans and the reest of the LFS editors for the fine book they produce. I recommend all Linux folk to at the very least just check out www.linuxfromscratch.org
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.
It really seems to me that the entire point of this "test" was to flaunt his new SCSI drives. I suppose some people feel the need to justify their purchases to a large audience in order to feel they didn't get a bum deal. Well done I say! Enjoy your badass drives and rest assured all the geeks from here to Babylon are impressed.
- I love animals. I try to eat at least one a day.
Seems like a pretty lame set of tests and results for this to actually get published. Would it have been *that* much more trouble to at least run a couple of the openly-available and easy-to-find disk benchmarking suites against both disks??
Sheesh....come on moderators....you can do better than this.
I don't want to start a holy war here, but what is it it with you SCSI zealots? I have been ssh'ing into my server (A Dual Opteron with 25000 rpm raid 0+1 SCSI drives) now for 20 minutes as it attempts to stripe a 17 megabyte file from one drive to the mirror drive. At home, on my Athlon 64 with 7200 RPM raid 0+1 IDE drives, the same operation would take 2 minutes if that.
Also, while this is happening, samba won't work, and everything else screcches to a halt. Even using vim on the ssh connection is stuggling to keep up as I type this.
Yes, I checked the obvious, DMA enabled, Cables inserted properly, but they are slow.
SCSI zealots, flame me if you like, but I'd rather hear intelligent reasons why I should use SCSI, over cheaper, faster IDE drives.
SCSI and Fibre Channel are 8 times faster in IO/s per second per single devices (in io salvos) and of course a dual SCSI 320 (two 320 megabyte per second connecotr) PCI-X card is only 181 bucks and gets you over 600 megabytes per second SUSTAINED on computers that have pci-x.
Apples sub $3000 dual g5 computer not only has dvd burner and up to 8 gig of ram, it offers pci-x at 133 Mhz per second... and has S-ATA, but most people want fibre channel and scsi on it for high speed storage. Why?
Sinple... uncompressed hiDef video is 1080 pixels by 1920 pixels, and has 30 frames per second and 24 bits per pixel (uncompressed).
Thats 172 megabytes per second PER STREAM with overhead and many video cards for uncompressed hidef handle two streams minimum for live effects.
HA!
Try getting >350 megabytes per second on IDE arrays or IDE card arrays or S-ATA anything.
And SCSI 320 is CHEAP.
A true scsi 320 fujitsu 36 gigger is less tahtn 155 bucks per drive and is an astounding +85 megabytes per second sustained on outter edge.
I can issue over 20,000 GENUINE unrelated and queued fibre channel SCSI 512 byte disk ios per second on a single connector of a dual connector fibre channel card on Mac under OS9 and on PCs under Windows 2000.
Can i ever issue 20,000 genuine unrelated adn queued S-ATA commands to a similar number of drives (over 10) or even an unlimited number of drives???? No!
Why?
Because IDE is horible for queued IOs despite all the big talk about new standards every year for 5 years.
SCSI has always been a little more expensive and a LOT more robust (3 year or more warrantees) and in 2003 scsi-320 is so fast compared to the fastest IDE adn S-ATA its hilarious.
Even better, the fastest S-ATA and IDE cost almost the same as the worlds fastest SCSI-320 drives..... except they are 8 times slower on average for top end arrays and tiny io as well.
Negligible gains over IDE? No. Significant gains.
RAID evens things out? No. The more disks you have to drive under IDE, the more your CPU bogs down.
Price/performance ratio better for IDE? No, under most circumstances.
SCSI is the only way to go if you care about speed. The SCSI commandset is also versatile - so much so that they borrowed it to extend IDE. IDE is ugly because the protocol is so closely tied to the hardware. Actual register addresses are part of the IDE specification, which just seems wrong somehow. And interrupts galore. Give me a nice smart SCSI controller (or even a dumb one these days) that only requires one or two register accesses to issue a command, and only interrupts at most once when a command completes. Yes, there are smart IDE controllers that hide most of this stuff from the system, but they still tend to run slower than SCSI controllers because their onboard CPUs, etc. tend to be much slower than that of the host system.
I once ran a test for weeks that drove 200 SCSI disks to the max, simultaneously on a single system (2 CPUs). The system had no trouble keeping the disks busy and still having power to spare. I don't think that would be possible with IDE - certainly not IDE drives directly connected to the system.
There are things about SCSI that are less than optimal, of course. I can't wait for the SCSI "bus" to die. It's too hardwarey. I worked on SCSI drivers/controllers for years, and nothing made it more agonizing than cabling problems. Bad terminators, bad cables, bad drive enclosures, argh! I was really hoping SCSI over Fibre Channel would take off, but that doesn't seem to be in the cards. Hopefully that will be solved some day soon with something like SATA.
How can anyone make such a ... hmm...er... ABSOLUTELY STUPID benchmark ?
First of all, the IDE drive only has 2mb of cache while the SCSI has 4mb. Now, cache is more important to IDE drives due to the whole IDE architecture. SCSI is a much better designed architecture...cache limitations aren't going to be as apparently obvious. This is very unfair to IDE drives.
Secondly, the IDE hard drive is on a 2.2ghz system. The SCSI is on a 700mhz system. While they both have 512mb RAM, it'll still give the edge to the IDE.
Third, I'm assuming they're both using Linux? Are they the same OS on both systems? Same version? Kernal? etc, etc...
Fourth, what IDE chipset does the 2.2ghz system use? Not all are created equally. Conversly, we know EXACTLY what SCSI controller is being used. Pretty nice one too.
Fifth. The author never told us the size of either drive and how full each drive is. It can make a big difference. It's not unlike CAV cd-roms. The read speed varies depending on what part of the platter the info is on.
We all know that SCSI can't be beat as far as search and destroy type missions go. Pretty good at mass data transfers too. I'd like to see the author compaire the SCSI drive to an ATA133 8mb 7200 HD of equal size on an ATA133 controller...both HD's with a mirror of the same exact information.
The SCSI will still win, but it would be nice to see how things REALLY stack up in a real world situation.
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
How on earth did this get moderated as flamebait?! This little bit of humor made reading the article and the ensuing barrage of pissed off (deservedly pissed albeit) slashdotters all worth while.
Even though the IDE drive was on a system with a CPU running at three times the speed of the SCSI drive's system, the SCSI machine took only 1/6 as much time.
/dev/null.
I stopped really caring at that point. I woulda thought somebody comparing the virtues of SCSI vs IDE would know that clock speed != processor speed. Redirect all posts about how he didn't count how fast the processor can crunch numbers in his (rather weak) comparison to
There are only 10 kinds of people in this world... those who understand binary and those who don't
Our test subjects
1 - 6 year old rabbit
1 - 2 year old turtle
To start with we have tied the rabbits rear legs together, then offered up a moldy piece of lettuce. The rabbits time in getting to this food was 38.4 seconds.
I then took a fresh piece of lettuce and stuck in inches from the turtles face. The turtle got the lettuce in 15.4 seconds.
From this test I can conclude that Turtles are faster then rabbits.
Next week we shall test if a Rage128 card is faster then a GF5900 using the Pong game, this should be interesting as I have the budget to only afford that game.
If firefighters fight fire and crime fighters fight crime, what do Freedom fighters fight?
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.
How did he transfer these 50, 000 files from one disk to the other? Did he replicate the filesystem image, or did he just copy the entire directory?
In the later case, the files would probably be much less fragmented on the destination disk. They would reside in consecutive order on the disk. Access would thus be way faster.
Also, he should use a filesystem that handles large directories more efficiently anyway. Candidates for this are XFS, reiserfs, or the ext3 version of Linux 2.6 with h-trees activated.
It's not that costly to outfit a machine with SCSI. I can get a used Adaptec AHA-2940UW for $5.00 and I saw an IBM PCI SCSI RAID card for the same. The cables are about $25-30 (1). The periphials can be about a $100 more over their IDE equivilent, but buying used can cut down on that. I also have the flexibility to move some of my SCSI internal devices to an external box. I've had this capability long before USB or Firewire even put in an apperance. (1) I can get those used for about $3.00 to $5.00. Used adapters are a bit harder.
The hard disk cache size has very little effect in linux boxen since the kernel uses as much memory as possible to cache hard disk data. If it's not found in 100's of MB of ram then it probably isn't in the disks cache, and yes system is ram IS faster than hard disk cache. I would be more interested to know what reorginazational effects copying the 50,000 file directory to the other drive had.
Reconfigure those four drives as RAID 1+0 if you really want to party.
SCSI offers interrupt coalescing... less tahtn one interrupt per SCSI IO is configurable.
To get over 20,000 Ios per second on a single connector (many Fibre Channel SCSI cards have 2 connectors per card) you need to coalesc interrupts.
for example 32 ios can share one interrupt on most LSI products (Apple's 499 dollar 2 gigabit Fibre channel card uses LSI) and 4 or 8 ios can share a single interrupt for io compltetion on JNI and QLogic controller chips.
High end SCSI-320 is no different. SHARED interrupts allow >20,000 ios per second per pci "function".
IDE-ATA on the other hand is revolting swill and not only wastes one interrupt per IO... historically it wasted one interrupt every 128Kilobytes (max ATA-IDE span used by most commercial drivers even in 2003)
the SCSI bus did not die.... it evolved into copper and optical "Fibre Chanel"
My room is filled with Fibre Channel gear, and its my main storage.
SCSI-320 cables are cheaper than S-ATA this week. (SCSi-320 uses the old standard scsi 68 pin cables)
So i disagree with your staements against the SCSI bus. Use laser optical 2Gigabit or 4 gigabit (10 gigabit soon) if you hate the scsi-320 68 pin cables.
I like all the cables and they never give me problems.
SCSI and Fibre Channel are 8 times faster in IO/s per second per single devices (in io salvos) and of course a dual SCSI 320 (two 320 megabyte per second connecotr) PCI-X card is only 181 bucks and gets you over 600 megabytes per second SUSTAINED on computers that have pci-x.
Apples sub $3000 dual g5 computer not only has dvd burner and up to 8 gig of ram, it offers pci-x at 133 Mhz per second... and has S-ATA, but most people want fibre channel and scsi on it for high speed storage. Why?
Sinple... uncompressed hiDef video is 1080 pixels by 1920 pixels, and has 30 frames per second and 24 bits per pixel (uncompressed).
Thats 172 megabytes per second PER STREAM with overhead and many video cards for uncompressed hidef handle two streams minimum for live effects.
HA!
Try getting >350 megabytes per second on IDE arrays or IDE card arrays or S-ATA anything.
And SCSI 320 is CHEAP.
A true scsi 320 fujitsu 36 gigger is less tahtn 155 bucks per drive and is an astounding +85 megabytes per second sustained on outter edge.
I can issue over 20,000 GENUINE unrelated and queued fibre channel SCSI 512 byte disk ios per second on a single connector of a dual connector fibre channel card on Mac under OS9 and on PCs under Windows 2000.
Can i ever issue 20,000 genuine unrelated adn queued S-ATA commands to a similar number of drives (over 10) or even an unlimited number of drives???? No!
Why?
Because IDE is horible for queued IOs despite all the big talk about new standards every year for 5 years.
Scsi drives are also made with more heavy duty parts that the ide drives. the standard warranty for ide is 1 year; the standard is 5 years for scsi. I've seen many cheap ide drives die in a year or two, but my scsi drives get much more of a workout in database servers and such, but just keep on going. I usually end up throwing out a perfectly good scsi drive because the technology is outdated, not because the drive dies. This durability alone makes the scsi worth the difference in price for me. Also the ide raid controlers suck. The cheapest scsi raid controllers work much better than some of the more expensive ide controllers ive seen.
These results and many of the other poster's anecdotal evidence suggests that SCSI drives would make good swap-space drives. The smaller maximum affordable capacities of SCSI would be OK for swap space use too. Has anybody tried doing that?
/.ers just buy more RAM.)
(I know, I know, real
Two wrongs don't make a right, but three lefts do.
or U-can with Beakman and Jax in the newspaper. That's what I thought of. Sort of a successor to Mr. Wizard, but a precursor to Bill Nye the Science Guy.
There is simply no way you can get 7x difference simply by switching an IDE HD to SCSI with similar specs. I always get suspicious when I see more than 2x difference. There must be something else. Either something is misconfigured or it is not an apples to apples comparison. Notice that the tests were performed on two completely different machines. The hardware and software configurations were not listed. Which versions of the kernel were the two machines running? Which versions of mutt? Which file systems?, etc. It will be quite funny if it turns out that the file systems are not the same.
For a more real-world comparison, check out http://www.storagereview.com/comparison.html . For instance, the web server drivemark lists various 7200RPM IDE HDs at 120-139 io/sec. The fastest 7200RPM SCSI HD, Quantum Atlas V scores 170 io/sec -- a 30% improvement. That is believable. The fastest 10000RPM HD, Quantum Atlas 10k IV, scores 261 io/sec - twice as fast as a typical 7200RPM IDE HD. That is also believable. The "benchmark" showing a SCSI drive 7x faster than a similar IDE drive is not believable.
___
If you think big enough, you'll never have to do it.
I'd also like to know what IDE controller was used. I was sorely dissappointed in the performance of the hard drive that came with my Dell computer using the on-board controller. I could really tell it was slow switching applications and booting up. It showed a rather pathetic score of 398 on PCMark 2002. I thought "to hell with that" and bought a new 160gb hard drive that was rated really well on tom's hardware. My score actually dropped to 244. That didn't make any sense. I updated all the drivers I could to no avail. Finally I bought a PCI IDE card at CompUSA for about $40 to try it out. The score jumped to 1216. That's almost up to the 1400 I have at home with my IDE raid setup, and much more than the 800 or so my brother got with his 10,000 rpm SCSI Cheetah drive.
Download the free version of PCMark 2002 and check your own hard drive scores.
From the is-this-worth-wasting-the-time-on dept:
My Pentium 4 is faster than my Apple ][. I did benchmarks!!!!!!!
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.
I have done similarly-informal tests myself, with comparable results.
I can't say I understand why SCSI performs so much better than IDE, however. In this particular test, he compared what amount to evenly-matched drives, specs-wise, and even gave the IDE drive the better machine. Yet, the SCSI drive completely crushed the IDE drive, no question about it. And as I mentioned, my own informal tests have shown the same results.
What explains the difference? Same spindle speeds, similar read rates (both buffered and unbuffered), similar seek times... What other factors exist that make so much of a difference? Just higher quality controller hardware? And if so, would an IDE drive on a high-end controller perform comparably?
Personally, I'll still take 4x the size for the same price, since cost and size (with "okay" performance) matters more to me than raw speed. But I wish I knew why one performs so much better than the other.
Take a look at this one, this guys (if i readed well) took a CHEETAH 10K U320 and pluged it with an ADAPTEC U160 PCI64 board.... -AND- then, plug the board on a PCI32 motherboard ?
:)
i'm not an scsi guru but... isn't that a really wonderfull waste of money !?
(sorry for my english; argentina says hello)
(let me help get you started)
vi? Emacs? What are these things of which you speak?
Ed is the standard text editor!
This test isn't good enough to convince me that SCSI is THAT much faster than IDE. I have both, and I sure don't see a blazing performance difference in favor of the SCSI. The person who did this review was too hung up on the performance of the drives themselves, but he didn't look at the capabilities of the CONTROLLERS. One of the advantages that SCSI controllers have over IDE is that SCSI has its own processor to handle disk I/O operations instead of bothering the CPU with them. A lot of times they even have integrated cache memory. With IDE that is not always the case. Most IDE controller chips on built into the motherboards are the el cheapo variety that just work, and you certainly can't expect enterprise-level performance from them like you'd expect with a $400 SCSI controller.
The other thing to consider is that the IDE controller drivers that come with Linux are generic, wheras SCSI controller drivers are hardware specific. In other words, way more optimizations can be thrown in on the driver level that would allow for better test results.
In conclusion, I bet if he used a 3Ware RAID controller with properly installed drivers he would see far different test results. It might still not be apples-to-apples, but it sure would be a lot closer.
-R
This is with no doubt at all one of the most useless, ridiculous, New-Wave-Science "benchmarks" I've ever even heard of. My only hope is that this writer doesn't work for the EPA or some other regulatory agency where such utter trash can be mistaken for science.
Don't take life too seriously; it isn't permanent.
You will never be Elite or 7331 till you have an Alpha or if you must buy IBM at least a Power4 with the dual core. PowerPC 970's or G5 are the hight of Lame or 74m3.
At work, at an isp, SCSI is king for the servers. Why? Lower seek times, faster rpm, if the drive has bad sectors i can boot into the scsi utilities on the card and tell the drive to work around them.
Also, i dont know about you but take for example a mail gateway that handles 150,000 emails a day. This is with spamd and amavis etc... You want more drives for scratch space. You want raid1. You want a seperate boot drive. This already sounds like 4-7 drives. Can u say proliant 7000?
It seems to me this is another case of price versus quality/testing.
Anyone in the biz does not care about the extra money when they know they are getting something they can rely on.
Reminds me of the gfx artist who pays for photoshop instead of using gimp for free.
Nonsense! What matters is how these 50000 files were distributed on the disk. The files in a mail directory are likely to be spread all over the place!
Linux does a good job at keeping fragmentation of files low. What matters in this case is however fragmentation of directory contents, or to put it in a better way, space locality.
If the guy copied the directory from one disk to the other, the files would be in consecutive blocks on the destination drive. This could easily explain the magical speed advantage he perceived in his test.
Boy, looking at some complex article like
i nd ex.html
http://www20.tomshardware.com/storage/20020305/
I was easily fooled into believing that modern IDE drives were actually faster than SCSI in some cases.
But unlike those hacks at Tom's hardware, here we have the real scoop.
Did you LOOK? The gains aren't 'negligible'. He went from seven minutes on a high-end ATA system to 1.5 minutes on an old beater SCSI box!
/dev/sda and all the 'big stuff' (file libraries, home folders) on my big/cheap ATA drive. It works GREAT.
Booting OS X on my Mac G3/450 takes 2 minutes with IDE, under 40 seconds with SCSI, and that's ATA/100 w/8MB buffer vs SCSI/80 w/2MB buffer.
I keep my portage tree, root, var, tmp, and swap on
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
The second - CPU utilization. A SCSI controller does a lot more work by itself than an IDE one - therefore it requires much less interaction with the CPU.
Then we have the bus bandwidth - this is probably no longer an issue, as ATA/66/100/133 can pipe enough bytes per second
Finally, the most important one - manufacturers simply don't make a 10k RPM hardrive IDE drive ... And 10k - 7200 makes a hell of a difference.
The Raven
Macs use SCSi320.
.
there is nothing "fanboy' about needing 172 megabytes per second per stream of uncompressed video.
SCSI and Fibre Channel are 8 times faster in IO/s per second per single devices (in io salvos) and of course a dual SCSI 320 (two 320 megabyte per second connecotr) PCI-X card is only 181 bucks and gets you over 600 megabytes per second SUSTAINED on computers that have pci-x.
Apples sub $3000 dual g5 computer not only has dvd burner and up to 8 gig of ram, it offers pci-x at 133 Mhz per second... and has S-ATA, but most people want fibre channel and scsi on it for high speed storage. Why?
Sinple... uncompressed hiDef video is 1080 pixels by 1920 pixels, and has 30 frames per second and 24 bits per pixel (uncompressed).
Thats 172 megabytes per second PER STREAM with overhead and many video cards for uncompressed hidef handle two streams minimum for live effects.
HA!
Try getting >350 megabytes per second on IDE arrays or IDE card arrays or S-ATA anything.
And SCSI 320 is CHEAP.
A true scsi 320 fujitsu 36 gigger is less tahtn 155 bucks per drive and is an astounding +85 megabytes per second sustained on outter edge.
I can issue over 20,000 GENUINE unrelated and queued fibre channel SCSI 512 byte disk ios per second on a single connector of a dual connector fibre channel card on Mac under OS9 and on PCs under Windows 2000.
Can i ever issue 20,000 genuine unrelated adn queued S-ATA commands to a similar number of drives (over 10) or even an unlimited number of drives???? No!
Why?
Because IDE is horible for queued IOs despite all the big talk about new standards every year for 5 years.
SCSI has always been a little more expensive and a LOT more robust (3 year or more warrantees) and in 2003 scsi-320 is so fast compared to the fastest IDE adn S-ATA its hilarious.
Even better, the fastest S-ATA and IDE cost almost the same as the worlds fastest SCSI-320 drives..... except they are 8 times slower on average for top end arrays and tiny io as well.
Apple, astera, atto, qlogic, all offer solutions for people needing far far more spped than using 4 s-ata high end drives by offering Fiber Channel (optical or copper) and SCSI320 and SCSi 160
pc people are closed minded and that is why macs have always dominated the high end video world. you need the speed.
macs ahve been faster than most Pcs for sustained IO every single year since 1986.
I hate all companies equally. I am no fanboy. But Macs rock for ios per second under os9 and for sustained CHEAP fibre channel using apples 499 dolalr 2gb fibre cards (yes 499 without tranceivers). Apples 14 drive fibre array is also THREE TIMES CHEAPER than any pc industry array the week it finally shipped. 3 times cheaper for same speed and more storage.
The reason is this thing called TCQ, or tagged command queuing.
See, for several years now, the old cylinder/head/sector way of addressing the drive has had very little resemblance to the drive's actual cylinders, heads, and sectors. This is because of BIOS constraints and other software limitations. So we have this thing called logical addressing (LBA) which treats the disk as one big one-dimensional line of sectors in a row.
So when you want to do I/O to a disk, the operating system usually uses a thing called an elevator algorithm to sort the I/O packets by their logical address in the hopes that reading the blocks in order will be faster than reading them out of order. Example: imagine a disk with 10 blocks. Which do you think would be faster? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 or 1, 10, 2, 9, 3, 7, etc?
But the thing is that the logical address has nothing to do with how the sectors are actually laid out on the disk. Remember, a disk is a stack of pancakes, not a bunch of sectors on a string. But without some kind of way of interrogating the disk's geometry and rewriting all the elevator algorithms in our favorite operating systems, we can't know what the optimal order is for our particular disk.
So why not have the disk re-order the I/O packets? This is the idea behind TCQ. What happens is the kernel bundles up a bunch of I/O requests and sends them to the disk all at once, and the disk services them in the order it thinks is best based on its knowledge of the geometry of the hard disk platters. This makes a bunch of little I/O operations to random locations a lot faster, and explains the Maildir behavior this guy is seeing.
So although older ATA disks are going to get their ass kicked by SCSI systems with TCQ enabled, we have new serial ATA disks that actually support TCQ! My brand new Western Digital Raptor 10K RPM disk doesn't support it though - you'll have to wait a few weeks for a new drive from Seagate which is supposed to be the first one on the market to support SATA TCQ.
In terms of throughput, SCSI disks usually win if you're buying quality parts. But the price of two ATA disks and a RAID controller is usually a lot less than a really big SCSI disk of the same size, so you can slap two ATA disks together and end up getting close to double the throughput for less than the cost of the SCSI system, as long as you're willing to have sucky random I/O for lots of small files. It's a great technique to use for video servers.
-- thalakan
Wow, the cluelessness of Slashdot people when it comes to technical stuff is a source of neverending amazement to me.
Just to fill you in here Dave, the bigger the hard drive the LESS time it takes to seek. If you had 5GB of stuff that'd take up over half the radius of the platter(s) on a 9GB drive, whereas it'd be like 1/7th of the radius on the 40GB drive. Seek time is dominated by start/stop (depends on the mechanism, SCSI has better mechanisms which accounts for the lower seek time, but also for part of the higher cost) and then by distance you have to go.
Your comment seems to imply you think that it is randomly seeking around hoping to find the data in question, or doing a linear search. Only in those cases would having a lower capacity disk help.
Sheesh.
The last drives I bought were
$50 each, and 20 GB capacity.
(from newegg.com)
I'd bet that for most uses,
these perform remarkably better
than SCSI drives of the same
price.
lsi21320 ooops i mistyped the part numebr of this monster...
i _h ba/downloads/lsi21320.pdf
:
http://www.bellmicro.com/fibrechannel/newasp/ls
Fusion-MPT architecture featuring 100,000 IO/s (interrupt coalescing)
With PCI-X throughput of 1056 MBps
BTW RETAIL box for 184 dolalrs of a DUAL channel , 3 connector card is at
http://scsi4me.com/
but many offer it for under 180 bucks as raw oem.
its an astounding card.
1. He uses completely different systems (in favor of the IDE system). Though, if he's picked a task which is really I/O dependant, it shouldn't matter much - but without further analysis, you can't know that.
2. MUCH more important: What about file system types? Both the same or not? Couldn't find that information. This alone could probably account for a VERY large difference between the tested systems.
3. Similar to 2, partition size. Depending on the file system used, could have a very large performance impact - e.g. a smaller partition might have fewer inodes (or in case of FAT based systems, might use 32KB instead of 4KB blocks)!
That said, I have no trouble to believe that, if the test setup would be properly configured, the SCSI drive would still be faster. But, I'd say that's because of the harddisk itself, and has not much to do with the interface. SCSI drives rock in access times (doesn't have anything to do with SCSI, just with the market the drives are built for), which is very important for accessing lots of small files - transfer rate is just no factor. The difference in cache size could also make a bit of a difference.
(SCSI has of course other advantages too, it's possible to have 15 devices on one bus, it has that nice disconnect feature, it still causes slightly less cpu load (though I'm not sure that's SCSI inherent or just because of better / more expensive controllers), but these don't matter in the context of this "comparison".)
The article has some more funny things: Don't think so. PCI-64 will help if running multiple drives together with Gigabit NICs or something similar - but the drive alone can push only 66MB/s so there won't be any performance increase by using a faster controller.
I can't speak for VXA personally. I never used it before. It looks like it's another contender to the DLT and LTO technogies though, which aren't "consumer-grade" at all.
(The web site you pointed me to advertises VXA drives starting at $999 - so this obviously isn't some "Circuit City" or "Best Buy" product for the masses.)
The tape technologies that really aren't worth anyone's time or money are the "Travan" drives, and increasingly, DAT drives. (All of the DAT auto-loaders I've used or seen other people use were terrible about having breakdowns, and the tapes themselves often wear out with repeated use, too.)
While on SCSI, I've noticed most of the brands such as Sony/Plextor/Pioneer make only IDE dvd burners.
IS there a comparable brand/model that runs as SCSI?
"hight" is the height of stupid or 57UP1D
I have been working with SCSI RAID-0 arrays for a while for streaming video, and have been very happy with them.
However, we just setup a prototype SATA RAID-0 system here's the info:
MegaRAID SATA 150-6 raid controller (raid-0)
6 WD Raptor 36 GB drives.
The whole thing was almost exactly $1,000.00.
Granted RAID-0 isn't for everyone, but for our applications we require very high data rates. We are seeing sustained 239MB/s.
Our previous SCSI setup is 6 disks at $600 each (at the time of purchase) plus a $1,200 controller. At that price differential even if the SATA's fail more often (which there is no evidence of) we can replace every component 4 times and still be better off then the SCSI system.
If anyone can do this on a SCSI system for the equivalent price, I'd honestly love to know it.
fire
LOL!! mod parent up!! (NT)
Performance and reliability benchmarks would be nice. I dont really care about adding in a RAID version as that dilutes the real comparison of a X vs Y vs Z type hard drives in head to head battle.
Anyone seen a report/analysis of this type?
We are a performance and reliability oriented web hosting company that uses exclusively SCSI hard drives for performance and reliability, but are wondering how close SATA is to SCSI for reliablity and performance.
Thanks
Greg
www.ZeroLag.com
I can't believe this article actually made it through. Did you guys read it? Come on. Slashdot has hit a new low here.
This is the lamest comparison of SCSI and IDE I've ever seen. A mail directory woopie. Hell, you can find some IDE drives that are faster than SCSI drives and vice versa. There's so much more involved than simply reading a lot of files or reading big file.
This doesn't even go into the variety of SCSI types nor the variety of IDE types. Both have a number of flavors and testing two or even three drives against one another is hardly conclusive.
Where SCSI really outperforms IDE is in multi-user environments, such as a file server or database server. SCSI's ability to offload work from the CPU, queue requests, and so forth make it much better for multi-user environments.
I have some software that will damn near kill an IDE drive because it creates a number of threads that perform a good deal of database work. On a SCSI drive that, for this kind of test (the one mentioned in teh article), might underperform IDE, would actually outperform on my software simply because of the way it works.
Man, I'm honestly so disappointed in Slashdot for posting this story. Slashdot has had much better SCSI vs. IDE comparisons in the past. I'd post one, but the Slashdot search is down and trying to find one on Google has prooven fruitless. Get your site together guys.
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"
Sticking feathers up your butt does not make you a chicken - Tyler Durden
It must say something about either reading from a CRT or HTML's click-click interface.
Read it again, there are 3 THREE disks tested
2 TWO SCSI one quite old, one a live server (i.e being used by other apps/deamons/services etc)
The other SCSI NEW on the WORKSTATION
Same level of fragmentation would have been on the 2 SCSI, the IDE we do not know
The NEW SCSI sliced the time in half (aprox)
Pardon my French but FFS everyone knows SCSI is kind to the rest of the system, says yes boss and gets on with it, whereas IDE/ATA sits there doing nothing until the CPU kicks its backside, its just how fast it gets up thats all thats changed with PIO/DMA/UDMA blah blah.
It's hard to tell which is faster, my Hitachi Lightning 9980 or my EMC Symmetrix 8830. Both seem to blow away a 40GB Maxtor IDE drive that I bought from Fry's.
"For the price of one SCSI drive, you can get 3 8MB cache IDE drives, plus the 3Ware card."
Do you pay full price for everything? I just got off the phone with a local dealer and I can get a used 68pin 9MB Seagate Barraccuda for $20, an Adaptec 2940UW for $5 (1), and if I look around I can get the cabling for $3 to $5.
(1) Or a 3 Channel IBM PCI RAID SCSI card for the same. And I generally trust the quality of same age SCSI equipment over IDE.
After all, he did this to get cover when she questions the purchase, right?
Why do I have this? I don't smoke.
http://www.storagereview.com/guide2000/ref/hdd/if
Here's the intro but read the FULL STORY through the link above for the details. StorageReview is a website devoted solely to benchmarking and reviewing drives:
Sunny
Be my Friend
I have noticed that a lot of the posts are stating the tests crap because
Personally I think the review was great, it didn't get boged down in numbers that most people do not understand (not understanding doesn't mean that you are stupid it just means you have better things to do with your time than learn everything there is to know about HDs) from a testing suite that most people have never heard off.
He is doing a personal review so he is using his own tests. Things that mean something to him. Ok I don't have 50000 emails or use mutt but I get the point of the operation. Personally I would have used database writes but that is just me
He stated in the very begning that he was looking only for a scsi solution, not the best price performance break point. So stating something like "I'd like to see the test of an IDE RAID array running off a 3Ware card " is really pointless. Also why do I want to fill up my already hot dual frypan (athlon) machine with 3-4 hot running IDE drives to get the performance of 1 scsi drive?
It said "windows 98 or better" so I installed Linux
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.
Here's a quick and dirty tutorial on why, in this particular setup and with these particular drives, SCSI smoked IDE.
Mostly it was the seek time. Seek time is the amount of time it takes to physically move the disk head from the center of the platters to one or the other edge. It is a pretty good indicator of the average time it takes to go from one spot on the HD to another.
The SCSI's seek time was 2/3 the IDE's seek time.
He was reading a little bit of the beginning of each of 50,000 files. These files are located in a single directory (or, perhaps, in a hierarchy, which would be much worse for the IDE - we'll assume the better case)
So the program asks for the first file name in the directory - disk seeks (in best case) to the sector with that directory's meta-data, grabs the first file (or, if Mutt asked for the files to be sorted by some file system metric, it gets and sorts all of them) and passes that information to mutt. Mutt then requests the first few bytes of said file. Assuming the disk cached a few sectors of directory info then it immediately seeks to the requisite sector, and assuming, as is usual, that the program will want more it reads and caches a few sectors of the file. Assume the file is not fragmented, and no further seeks are required.
Mutt closes the file, then requests the next one. Here's where it gets really messy. If you're lucky, the file system and OS are set up to cache the sorted directory information. But even the unsorted information, for 50,000 files, is unlikely to be cached - so it has to seek back to the original directory sector (possibly re-sort) and then spit out the next. Then it seeks back to the file.
The time to read the data and spit it out is negligible compared to the seek time for small data reads.
Each file read typically takes a minimum of 2 seeks. I say minimum as most modern file systems use a directory information hierarchy which is fairly simple, but it may take more than a few sector reads to find the location of a single file in a directory with a huge number of files.
The SCSI drive has a larger cache. It will see, just as the IDE drive does, that the directory info sectors are being hit hard. Guess which drive is going to be able to cache those sectors better?
Also, for those wondering why the older 9GB scsi had better seek time than the newer 40GB IDE, it is because of the capacity. The head has to settle on a given track before it can read it, and the track isn't just 4 times smaller, it's possibly even 8 times smaller because newer drives have a servo position indicator track between each data track so the heads can crash around and find the right spot quickly. Since the head has to be 'focused' on such a smaller track, it takes more time to settle. This doesn't even take into account that the older (and larger for the time it was built) scsi has more platters than the IDE, and each track is again much larger.
Lastly, I suspect that his mail directory was built over time on the 40GB drive, then copied over to the SCSI drive. Can you say fragmentation? Not just of the files, they are small and probably only require one sector each to read. The directory information, however, is not contained, as one might assume, in one contiguous string of sectors. When another file is added, if the directory expands to another sector of meta data then it'll pick the next free one according to the file system's particular design. It may take up to hundreds of full seek times to find the starting sector of a recently written file. A fair test...would be difficult. Put the same exact file system, down to the same sector by sector data (use ghost or something) with the minimum modifications (scsi drivers) on the same computer and you'll have a fairer comparison.
All of this leads to the undeniable fact, which the author so misguidedly states that, "From my testing I concluded that SCSI being faster than IDE is not a myth. It is very much a reali
I was reading through the messages and people seem to think that higher RPM would mean more power use. I do not think the higher RPM is much of an issue since once the spindle is up to speed it is not drawing much power anyway. What uses power on a hard drive is the motor that moves the heads across the cylinders.
:) .
A hard drive performing a seek operation has to do several things.
1. Move heads to correct physcial location on the platter.
2. Stop the heads over that location and wait for heads to stop bouncing, (you just accelerated them a bunch)
3. Maintain that position as the data is written or read.
4. Repeat until all data is written or read.
To reduce access time you need to improve a couple of things.
1. You can make the head assembly stiffer so it will bounce less. This means more mass or more expensive materails.
2.You can increase the amount of force the head moving motor can generate, making it seek faster. Once again, you increase the mass as well as increasing the current needed to perform the work.
3.You can make the heads smaller and the tracks narrower to it has to move less. Again more expensive materials required.
Spindle speed not only does not effect power consumption much it does not effect data throughput in the average read write applicaton since you are most often moving the heads and waiting for them to stop bouncing.
My guess is that SCSI drives, which on the average are of smaller capacity than IDE drives, are built with stiffer head assemblies and faster head moving motor speeds.
One other thing to consider is media quality of the hard drive platter. Most IDE drives have a built in table to track the bad spots on the platter. A normal hard drive may have many sections of bad spots that the enduser never sees since the integrated drive electronics automatically remove them from the drive's acceptable data areas. This means that you could have fragmentation due to these factory bad spots even if your drive shows no fragmentation at all.
I am guessing that SCSI drives media quality is much higher than the IDE drives because it has to be. This would result in much less hidden fragmentation.
It is the same old same old, FAST , CHEAP , GOOD. Pick any two,
dzimmerm
Jumping to correct solutions slowly is better than jumping to incorrect solutions quickly.
If you are going to "benchmark" the drive performance, why not use a filesystem benchmarking tool like IOzone? From http://www.iozone.org:
,mmap, aio_read, aio_write.
IOzone is a filesystem benchmark tool. The benchmark generates and measures a variety of file operations. Iozone has been ported to many machines and runs under many operating systems.
Iozone is useful for performing a broad filesystem analysis of a vendor's computer platform. The benchmark tests file I/O performance for the following operations: Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read, pread
Okay, I know it's bad form to reply to your own post, but I thought I'd add the results of a little Pricewatch search I ran.
I said in my earlier post that you can get 3x8MB cache drives plus a 3Ware IDE RAID card for about the cost of one SCSI drive. Here are the actual cost breakdowns. All prices include shipping.
IDE SYSTEM
1 x 3Ware 7500-4 4-port RAID card: $250
3 x Western Digital WD800JB hard drives (IDE; 80GB; 8MB cache) = $219.
TOTAL for IDE system: $469.
Total usable space: 160GB.
Bonus points for RAID-5 redundancy.
SCSI SYSTEM
1 x Adaptec 29320 U320 SCSI adapter (64-bit PCI card): $179.
1 x 73GB U320 10,000RPM drive by Maxtor: $296.
TOTAL for SCSI system: $475.
Total usable space: 73GB.
Bonus points for raw speed.
Now, if you want to run a real benchmark, pit these two systems against each other in a nice server (dual Xeon preferred.) Make sure it's the same hardware being used. This would be a benchmark that I'd be interested in seeing the results from. I'd take any test pitting these types of systems against each other a lot more seriously than any "benchmarks" in the current article.
Simpli - Your source for San Jose dedicated servers and colocation!
I have an IDE drive in my computer and I am happy with it. It does the job and I can afford buying more space because IDE is cheap. Now a SCSI drive is going to be faster, and it is going to cost me an arm and a leg
You have to remember that one BIG difference between IDE and SCSI is that SCSI uses an indepdent controller for doing the work. IDE on the other hand use your processor. This means the performance of an IDE driver is totally dependent on the load and the processing ability of you CPU, whereas SCSI is dependent on that of the dedicated controller.
Other things to take into account is that the reason you pay more for a SCSI drive is because all the supporting hardware, such as cache and processing circuity, is of higher quality and specs than that of an IDE drive. To get the same sort of quality and specs, with an IDE drive, then you are almost going to need to wait 5 years. People using SCSI drives don't want to wait 5 years so putting the money down now is the only option.
There are surely tricks to getting an IDE to perform as well a SCSI drive, but how much do you have to pay to do that? Most people want a working solution that does not require 3 more months on their schedule for something that may work.
IDE is a cheap solution that does its job, SCSI costs more but it also does its job.
Its your money, spend it as you wish, but don't complain if you cheap out on the wrong thing.
Jumpstart the tartan drive.
look at the real data. storagereview.com has extensive data on most hdds out there today. the top top is almost always SCSI. is it more expensive sure. but which has the most performance dont even blink. Its SCSI(expect for 2 tests).
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..
Blessed are the pessimists, for they have made backups.
How many times do we have to sit through another IDE vs SCSI debate? Hasn't this been going on since 1980? I think we should start debating what is better Hard Drives or 5.25 floppies. I think floppies are better because it forces idiot companies to not write bloatware. Plus software that takes 10 minutes to load means that your work day is going to have at least another 10 minutes of break time. If your computer crashes a lot you could have as much as 2 extra hours of 'break' time each day.
Hey buddy, run this on your IDE drive (after you man hdparm, of course). I'll bet you'll see a difference. My drives go from around 3-5MB/sec to 25-35MB/sec. /dev/hda
hdparm -c 1 -d 1 -a 8 -u 1 -m 16
Linux defaults IDE drives to pathetically slow settings. This is because there are/were a lot of bad IDE drives out there, so conservative settings are used as defaults to avoid data loss.
http://www.anandtech.com/printarticle.html?i=1799
10k-SCSI vs 10k-SATA vs 7.2k-SATA vs 7.2k-PATA.
Whenever the offence inspires less horror than the punishment, the rigour of penal law is obliged to give way...
Performance: Fibre Channel
Performance/Price: SATA
Fibre Channel uses (it can use other high-level protocols, true) SCSI commands... and it's serial... as similar to SCSI as SATA is to IDE...
http://www.serialattachedscsi.com/
is a link to SAS info. SAS is SATA with SCSI protocol.
.. Blub falls right in the middle of the abstractness continuum. -- Paul Graham
Although, the article does look lame and unimpressive, I did find some interesting facts from ... comments of /. users. Was that the primary purpose to publish this article?
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
apparently *your* box is not "elite" enough to have a spell-checker.
short and sweet
Any preoccupation with ideas of what is right or wrong in conduct shows an arrested intellectual development. (Wilde)
If you pay for a good, high-end IDE card, they do tend to still last awhile too. I've noticed a lot of failures around the area of 30-40GB cards (particularly we've been returning a lot Fujitsu's on warrantee, which we're named fucrapsu) - but the higher end drives are decent. My 60GB drive, which was big at that time, is still working fine. I'd expect that the 200GB and expensive drives are still fairly reliable as well, and bang-for-buck wise they hold a lot more.
Not to look down on SCSI though. We've got a lot of old SCSI ultra-wide's that kick ass still... but at the cost it's still cheaper to buy two IDE's and just use RAID-1 on 'em.
For high end performance SSA is way faster than SCSI. Way more expensive too. But if you actually need gobs o speed this is the way to go. They are beastly hard to tune in array setups though. Several hundred MBps is the starting point.
Heh. I just picked up an LSI 22903 SCSI card on eBay for $15. It's a low-profile PCI card, so you have to take the bracket off the back if you want to use it in an ATX case. It's a 64-bit 66 MHz card (though not PCI-X if I understand right) and I happen to have a matching slot in my Tyan Tiger MPX board.
Why bother? Because I have a pair of Maxtor/Quantum Atlas 10k IV U320 drives with sustained transfer rates of 72 MB/sec. When I set them up in a RAID-0 array with my Adaptec 29160N controller (32-bit, 33 MHz) I think it maxed out my PCI bus. I'd only get 95-100 MB/sec sustained transfers. Should have been nearly double the 72 MB/sec for a single drive.
Do I need that kind of speed? Not really. Ok, not at all. This is my personal machine, not some corporate server. My thinking was more like "How cool would 144 MB/sec be?"
Anyway, I also have a RAID-1 IDE array (same machine) with two late-model Seagate 80 GB drives and I can't get anything near that on reading (wouldn't expect it on writing as it has to mirror the data, right? But on reads it should interleave much like RAID-0 would). I get more like 30 MB/sec with the IDE RAID setup.
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
7 minutes to 28 seconds? I don't doubt the numbers he saw but I wonder if he was comparing apples to apples or not. There are tons of things that could have given him false (or inaccurate) data like fragmentation differences, bios settings (think DMA), where on the drive the data was located, and on and on.
I agree with another poster who suggested using a real benchmark utility. People see what they want to see. He saw 7 minutes to 28 seconds. I haven't decided what I'm seeing yet...
did someone pull a switcheroo on this article? when I look at the linked page, I see a very tongue-in-cheek article which seems designed to demonstrate quite possibly the worst possible comparison. no, wait, he could have used windows ME for one of the machines!
;)
seriously, a 6-7x difference in performance is simply not credible. the only way you can achieve something like that is, for instance, to disable write caching on one disk and not the other. or perhaps not bother installing the chipset-specific driver for the ata interface. please, someone send me some disks, and I'll happily do a real, honest comparison!
However, since most SCSI hard drives have more cache, higher spin speeds, and lower seek times, they tend to be faster by virtue of *those* attributes. In time I expect SATA RAID will give us all the best of both worlds. Cheaper, more reliable, better performance, and greater capacity per $ doesn't look to be that far off.
http://marc.theaimsgroup.com/?l=linux-smp&m=902223 42930942&w=2
2 22342930991&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=90
not price.
However:
4x SCSI 36 GB 6.9ms 300
1XLSI card(better then adaptec) 117
Cost 417
Useable space 145GB
raid them.
Bonus point for raw speed.
Bonus points for easy on the processor
bonus point for real world speed
bonus point on cost.
bonus point can add 26 more drives.
bonus point cleaner implimentation of the protocol.
I used to do these kinds of test daily. I used to have to write low level SCSI code, and test IDE code.
We had a boss who wanted us to go IDE, but they could never match speed and reliability.
Does it matter to the browsing email use crowds? not one bit.
However, I always put SCSI drive in systems I build now.
The new IDE stuff coming out is noce, but so is the new SCSI stuff.
The Kruger Dunning explains most post on
Mac or Apple?
t ml
sequel or ess-que-ell?
SCSI or IDE?
How you you pronounce FAQ?
Tomato or Tomato?
George, Ira come back! all is forgiven!
Seeking Enlightenment to the great answers..
I forsook the Milliard Gargantubrain and checked out google a few weeks ago..
It's not that recent but it may ilght the way to further work...
http://citeseer.nj.nec.com/white01performance.h
cheers,
Bob
----
-- Give it back, Georgie, it's not yours!
Facebook is a woodpecker tapping on the skull of Humanity, Forever.
nt
The test as conducted is probably slow on IDE because the O/S is seeking over and over again to read each file, probably re-reading the directory structures in between each file access.
I stuck 50,000 messages in a Maildir on a FreeBSD 4.9-RC server, 2.2GHz Celeron, 256MB RAM, with a 7200rpm 60GB Western Digital IDE drive, 2MB cache. The kernel has UFS_DIRHASH and SOFTUPDATES enabled. The directory really gets read once, which makes a huge difference.
mutt loaded all 50,000 messages in... wait for it... 18.15 seconds.
I'd have to say this isn't a particularly good test, but also that the way to improve things isn't always to spend more on the hardware.
K
True, that. We originally (like 6 years ago) wanted to eliminate the need for some one to administer our machines as much as possible, so we bought a travan drive for each workstation, so people could manage their own backups. Between having to send the drives back every 4-6 moths for repairs and the human factor of even the most otherwise intelligent people failing to learn tar or even Arkeia we decided to invest in a "global solution". We went with VXA and have been very happy.
Now things are getting a little tight, and our nightlies are barely fitting on one 33GB tape. VXA-2 seems to be one upgrade path, but the LTO Ultrium capacity is really impressive. Have you used such a drive? How are they?
People are bitching about how it's not worth testing Serial-ATA against fiber channel SCSI because of the differences in technology -- serial vs. parallel -- and this makes no sense to me at all, so help me out here!
I agree that this test is sort of pathetic. I'd MUCH rather see how S-ATA stacks up against Fiber Channel. Any thoughts?
-----
"Cogito Eggo Sum: I think, therefore, waffle."
and not only that, SCSI in the typical tradition of the fragmented unix world has no standards at all. Too many variations, too much cost too much foolishness.
Sure, we've seen the comments regarding spindle rpms, cache size/speed, and so on. What about the actual file systems used here? Doesn't ReiserFS have equivalent read access for smaller file structures as the large streaming ones?
with a 30gig harddrive. They got a "great deal" and were very happy...
So I've got the old, obsolete server sitting right here. It's "just" a P3 (yeah, both CPUs
Hold on a second... Okay, I just pulled one of the SCSI drives out of the "obsolete" server. It's still grinding away with SETI@Home.
Cheap IDE for a desktop, SCSI for a server. Apples and oranges.
"Fear is the rootkit of democracy.." Blarkon
Why isn't his test, done with real world data, not a 'real world' test?
If the speed difference is really caused by differences between the drives/protocols, it is an interesting result. The smaller seek time on the SCSI drive could be part of the reason, but certainly not the entire reason for such a large difference. The larger buffer on the SCSI drive is also an advantage, but I don't know how much difference that does. It would have been interesting to throw in an IDE drive with 8MB buffer in the test. However there are a few details he completely omits from his description, and I'm afraid he have forgotten about those. The filesystem used, and the fragmentation of the drive is important. Using a different filesystem on the two drives could cause such a large difference. Besides the old drive probably being fragmented, and the new drive possibly not being fragmented could also cause the difference. Making a raw copy of a partition from one drive to the other would have ensured those factors were also the same.
Do you care about the security of your wireless mouse?
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.
(eom)
I don't even care which one is faster because to me SCSI is just much more sexy than IDE[period]
Damn right. SCSI costs more, and people still set up with it. Must have something going for it. Like, oh, beingabletousemorethan onedriverpercontroller perhaps?
You know, the one where Dogbert invents chronic cubicle syndrome based purely on anecdotal evidence? Here's some real benchmarks, courtesy of storagereview.com, fastest SCSI vs fastest IDE:
SR File Server DriveMark 2002:
Fujitsu MAS3735 (73 GB Ultra320 SCSI) - 366
Western Digital Raptor WD360GD (36 GB SATA) - 192
SR Web Server DriveMark 2002
Fujitsu MAS3735 (73 GB Ultra320 SCSI) - 355
Western Digital Raptor WD360GD (36 GB SATA) - 189
These are the tests where the SCSI disks shine - in the desktop benchmarks, they aren't ahead by much. As you can see, they don't even double performance, so whatever this guy was doing he was doing it all wrong.
As for the future, the new two-platter WD Raptor will have tagged command queuing, which should give it a good boost in a server setting. Also, the fact that you can easily have an IDE RAID 1 array with cash to spare for the price of one SCSI disk + controller kinda evens the reliability out, IMO.
Kjella
Live today, because you never know what tomorrow brings
Read it and weep mac luser.
my sig could kick your sig's arse...
What you want is an IBM "Enterprise" tape drive. 40MB/s native streaming speed and 300Gb native capacity. The average drive compression ratio is 3:1 so you can get 120Mb/s and 900Gb on a cartridge.
Not cheap though.
Government of the people, by corporate executives, for corporate profits.
For what it's worth, I am the chief recording engineer of a professional recording studio. All our multitrack recording goes to hard drives these days. DSP and streaming 80 tracks of 192 kHz 24-bit data are both I/O and CPU intensive - continuosly reading data from all over the disks and processing it.
Now, what I've noticed in a lot of SCSI vs. IDE speed tests is that most ignore two very important things: CPU consumption and continuity of throughput, both very important for our purposes. I've done a lot of comparisons of my own, and unlike the reviewer, I've actually always used the same exact drive in both SCSI and IDE versions when testing. The conclusion? SCSI sweeps the floor with IDE. IDE requires a lot more CPU (all pro audio apps have CPU and disk throughput meters so this can be measured easily) and there are many more problems with them in general.
For example, I've witnessed cases of an IDE drive introducing crackles and pops in the audio (as if it's not keeping up with the data stream) when a SCSI drive with the exact same specs from the same manufacturer works perfectly. Let alone the ease of setting up SCSI RAID arrays etc.
This may not be very important to a home user, but to me it seems there is never enough power in any computer or mass storage device.
while true;do echo -e -n "\033[s\n\033[u\134_\033[B";done
variations? ok, there are many, that's called technological advance. but scsi _always_ kept backwards compatibility.
I wrote this months ago using newer hardware and comparing RAID arrays as well:
Comparing Hard Drives
It was really meant to be a comparison of brands, RAID vs single drives, and SCSI vs. IDE. At the time SATA wasn't out yet and I couldn't get any SATA drives to add to the comparison later.
-JemHis workload looks likely to be fsync intensive, and this is probably the main reason for the performance difference between scsi and IDE. Linux drivers handle write barriers better for SCSI than IDE. For most usage patterns, 2 IDE disks are going to outperform one SCSI disk and cost less.
I never buy SCSI.
I don't have any fsync intensive workloads, and the price just does not compute to buy it for me. SCSI is a marketing segmentation mechanism designed to get dumb corporations to spend more money.
athlon root # hdparm -T /dev/hda /dev/hda: /dev/hda /dev/hda: /dev/hda /dev/hda: /dev/hda /dev/hda: /dev/hda /dev/hda: /dev/hda /dev/hda:
Timing buffer-cache reads: 1760 MB in 2.00 seconds = 880.00 MB/sec
athlon root # hdparm -T
Timing buffer-cache reads: 1748 MB in 2.00 seconds = 874.00 MB/sec
athlon root # hdparm -T
Timing buffer-cache reads: 1720 MB in 2.00 seconds = 860.00 MB/sec
athlon root # hdparm -t
Timing buffered disk reads: 136 MB in 3.00 seconds = 45.33 MB/sec
athlon root # hdparm -t
Timing buffered disk reads: 140 MB in 3.02 seconds = 46.36 MB/sec
athlon root # hdparm -t
Timing buffered disk reads: 140 MB in 3.04 seconds = 46.05 MB/sec
This was done at the same time as I'm playing a ogg file, encoded at quality 10.
I think that my athlon-xp 2500+ (burton) with 1 GB of ram has something to do about it.
hda: WDC WD800JB-00CRA1, ATA DISK drive
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63, UDMA(100)
And?? Model number? Western Digital has been making 40+ gig drives since Summer 2000, so for all we know this drive is almost 4 years old.
I don't have to remind everyone 4 years is a few generations in computer years. Next time you do a review how about telling us the drive number, or do a review using modern drives.
Anyone want to read my review of my p3 600mhz?
my karma will be here long after I'm gone
But the 1541 didnt do that by default, nor did Commodore intend anyone to use the drives that way - they only had about 2k (ish) ram onboard, and sent the data down a serial IEEE at very slow speeds. It was only much later that people hacked the on-board 6502 to send data at 35x normal speed - the controller would spew data from head->main c64 a full track at a time. With no turbo boost, it took about 20 minutes & 4 disk swaps to copy a 170K floppy on a single 1541.. When people wax nostalgic for old 64's they forget that part..
"You lied to me! There is a Swansea!"
Um, yes, they didn't copy disks that way by default, but it wasn't because during file transfer the machine was too busy positioning the heads, etc -- it was because the damn machine only had 64K of ram and 170K disks! Also, you're talking about a single drive configuration, in a dual disk configuration you didn't need to switch disks, unless you had a retarded copying program.
Which kind of makes my point, you needed a copying program, the machine didn't copy disks natively, it didn't know *anything* about disk drives; just serial I/O. Hmm, I think the CBM 4040/8050/8250 might've had a way to copy from disk 0 to 1, I forget now.
Again, to reiterate, the C64 did not busy itself with head positioning, disk rotation, GDR decoding, etc., that was the drive's job. The fact that to copy a disk you needed to tell it to access each sector is completely irrelevant. You could do the same thing (with a non-copy protected disk) by traversing the directory and opening each file one by one.
Do daemons dream of electric sleep()?
You miss my point - sure the 1541 had its own 6502, 2k RAM, ROM - but that 2k is not enough to hold a track all at once. So in normal mode the 1541 would read a sector of a track, then have to wait while it sent the data to the host CBM 64 (about 256 bytes a second, I think!), then wait for the disk to spin around again and read another sector..
Finally some genius figured out a piece of code to sit in that 2k RAM which could send data straight from the 1541 read head to the host 64 "on the fly", track at a time at 35x speed. But this was a system hack.
So in fact, with all the "turbo" copiers/file systems that came in at the end, the 64 *did* have to control the 1541 on a track by track basis. The 6502 in the 1541 was really a "dumb" controller in this mode..
"You lied to me! There is a Swansea!"
First of all, the idiot didn't even take the time to make sure the drives were evenly paired. He tested an IDE drive with 2 megs of cache against a SCSI drive with 4 megs of onboard cache. I own an IDE drive with 8 Megs of cache on it and it absolutely screams. I do realtime audio editing and capturing with it with the onboard controller and am completely satisfied with the performance I get out of it. As we all know, if we're talking about drive access times, those access times and read times are a function of the hard drive and the controller, irregardless of the processor speed. I'm not saying that scsi isn't faster, because the times the author of the article reported are correct, and scsi is indeed faster. What I am saying is that had he been more fair in his selection of testing components and ensured that they were nearly identical where cache and access times were concerned he'd have found that the difference between the two technologies would have been greatly reduced, and therefore his testing method, while still proving there is a difference, was flawed in that it gave an unfair advandage to the SCSI technology via the 2 meg cache difference, and still more unfair during testing with a 6 meg cache difference on the "new" SCSI drive.
is because he just shelled out $700 on his new drive.
so, he has to make it out as good to prove to himself what he just bought will beat ide.
also, not to mention he never stated brand names.
certain manufacturers are very different.
How can an IDE RAID controller efficiently order reads and writes when it can't know the true drive layout?
At the very least, (AFAIK) both SCSI and IDE drives will remap bad sectors into unused (spare) space in a way that is invisible to the controller. Plus, there are more sectors per track as you go further out toward the edge of the platter. The geometry that is presented to the controller is synthetic and fake (it's been a long time since I've seen a drive with 16 heads).
Without an intimate knowledge of the drive geometry, how can reordering reads/writes be done efficiently?
He didn't factor in the cost of of the chickens needed to get SCSI working properly, nor the cost of clean-up once thing thing is done.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
You assert, "This type of stuff can be found in any newsgroup or forum on a daily basis."
Did you ever think that the sum of those posts might reflect something like the truth? SCSI has always performed better than IDE in any box I've ever built. SCSI I with it's pathetic 5MB/s works better than IDE I with 16 in older Pentium class machines. 40MB/s SCSI controlers have worked better for me than more modern IDE drives. I've never bothered to run benchmarks, I just watch the system stall under IDE and curse.
Reading posts from other people reporting the same types of stuff keeps me from being tempted to blow money on fancy IDE controlers. The next time I build a system, I'll give the cheapo IDE controler on the mobo a whirl. If it disapoints me, I can go SCSI. For $40, I can find a nice new card. For less than that, I can get used hard drives on ebay. IDE speeds are impressive, but something does not connect.
Friends don't help friends install M$ junk.
I've seen this debate go on for years. the only people I've ever seen say IDE is better than scsi and doesn't warrant the price ARE PEOPLE WHO NEVER USED IT!! current SCSI technology is like almost 5 years ahead of IDE technology. just because your little IDE drive says it's ata/133 doesn't mean it will ever achieve that speed. you really need to look at internal transfer speeds of the drives. if the internal transfer speed doesn't even get to 1/2 of the external transfer speed, than they're just equipping a crappy drive with a screaming interface.
SCSI drives on the other hand are built from the ground up to offer the most performance they can possibly muster out of existing technology (without costing many thousand dollars). SCSI drives also have like 2x the MTBF of IDE drives. I still have some old 1 and 2gb scsi drives that work perfectly and still are faster than current large IDE drives.
frankly anyone ignorant enough to to say IDE is better than scsi doesn't deserve scsi in the first place. I'm extreemly happy with my 15,000RPM scsi drive (that I payed only $200 bucks for NEW with a 5 [yes thats FIVE!!] year warranty). I can defrag (in winblowz) a 36 gig partition with 40% fragmentation in just under 5 minutes. try that with a crappy maxtor!
I had an older article that performed MUCH better! No seriously, I did not see any listing of what transfer mechanism the home-made disk driver was using on the IDE system. For all I know, his system isn't detecting properly and is using PIO mode for data transfer. To respond to another poster, if it took me 7 minutes to read in the mail, I would be trying to find what the real problem was.
Crunchy vs. creamy?
-- No sig for you!
Look at it this way.
It cost the author $525 to enter the SCSI game with a single disk and a reasonable controller.
How much would he have spent on a 3 disk IDE RAID with a deep (128 MB) cache?
About the same but with a hell of a lot more storage capacity. As for speed, the gap would narrow but I don't know if a 3 disk RAID and 128 MB cache would completely erase so large a gap.
--= Isn't it surprising how badly I spell ?
ATA? SCSI?
I use Fiber Channel, you insensitive clod!
The RAID controller would re-order I/O by grouping "near" sector addressess together. (SCSI has always used LBA-type addressing, IDE can't live without it now.) The on-drive controller has to be set up so that is a reasonable thing to do, that writing block 1, 2, 3, 4, 5 minimizes head seek and rotational latency. Sometimes you're going to have a stripe cross a cylinder boundary; but that's just one crossing, you won't be dancing back and forth over it while writing that portion of the stripe.
TCQ allows the drive controller circuitry itself (downstream of a SCSI controller) to re-order writes; the host adapter issues writes for blocks 1, 1001, 2, and 1002, and the drive controller says, "done 1, 2, 1002, 1001." The controller circuitry does know the geometry; it has to.
So sure there are issues with not knowing the geometry, but it turns out to not really matter after all; with the disk buffer to absorb the track-to-track delay, you're fine. (As long as seeks don't dominate your I/O, which is what the test was about.)
I don't think anyone sensible would doubt that--other things being mostly equal--SCSI is faster than IDE. But this result doesn't pass the smell test. The IDE seems just too slow to be plausably due just to IDE drive vs. SCSI drive.
Note above that I wrote "IDE drive vs. SCSI drive" not "IDE vs. SCSI". IDE and SCSI drives differ in more than their interface. It will never make sense to do an exact match of drives. A sensible comparison would be to put together a high-end box with high-end IDE drives in it (including medium-end technologies such as raid), and match it against a SCSI box with similar specs and a vaguely similar price point. The result will be an IDE box with significantly more storage capacity and a SCSI box which still costs a bit more than the IDE.
The SCSI and IDE markets are different, but they do overlap. To compare the two we should choose tuned configurations that are in the overlaping region. If we do that we will still find that SCSI is faster than IDE, but I would be interested in how big the performance (and price and capacity) difference is.
-kb, the Kent who, were he to put together the fastest possible box with price no object would certainly use SCSI (or fibre channel), but also the Kent who, considering the extra dollars, space, heat, noise, and complexity of a matched-capacity SCSI box would seriously doubt the benefit of SCSI.
word.
It's not the storage capacity that matters in a lot of cases, it's the throughput.
I have a similar potential need. I run Squirrelmail on my Red Hat box at home hosting my mail, and for the longest time I was using an IDE drive to hold it, because IDE's cheap, and was even more so 3 years ago when I first put the box together. My mailbox is taking 20-30 seconds to refresh after an operation, since it's admittely huge. The mainboard I used in building the server was a cheap QDI dual processor board that I got for $130 and slapped two celeron 466s on it, good deal! It also has an Adaptec 7880 controller built into it that I never used since the cost of SCSI drives was even more than it is today.
In light of this test, I am really curious to see whether or not I would get a boost in performance by moving my mail onto a small (18GB) SCSI drive instead. I don't need a huge amount of storage for the mail, and I can use IDE drives for the main stuff I do with the server, but having faster mail performance is something I've been trying to do for a while. I had planned a whole new box, but I think I'll give this a go first and see what happens....
I've personally never owned an IDE device. One of the nifty things about SCSI is the large number of devices it can support concurrently. When I need more space I just buy a new drive and relegate an older one to storage for backup files--I typically have 2-3 CD type drives and 3-4 hard drives installed. Is IDE really that much cheaper if the drives fail in half the time? In the 14 years I've been using SCSI at home I've yet to have a single device fail on me. The only thing that sucks about SCSI is the constantly changing bus standards. In the time I've had SCSI devices the SCSI connector format has changed probably 3-4 times compared to 0 with IDE.
I did that once. I've never bought a SCSI drive again. What a waste of money. If you're that anal about performance spend the same money on an Escalade RAID controller, 4 IDE drives. Then set up 0+1 RAID. I'll bet you get faster speed, more capacity *and* you'll have fault tolerance.
First, check your IMAP server. If you are using UW-IMAP, scrap it. Replace it with Courier-IMAP, Dovecott IMAP, or even Cyrus. I'd recommend either of the first two, though.
Before throwing more hardware at it, tune the software side of things. Check your filesystem settings, your IMAP settings, your Apache settings, your SM settings. These are things that will give you a larger payback in total system responsiveness/speed that just throwing a larger/faster harddrive in there.
If I recall, that code also managed to use the serial cable as a two-bit parallel cable....
I'm calling bull on you, but your example doesn't matter anyway.
Are you saying that SCSI drives will magically correct for idiot users? What good would that machine have been if it would have booted? Doing a lot of floppy-based work these days?
Any performance advantages SCSI drives have over ATA/IDE must surely only come from the way these protocols have been defined, at the command-set and interconnect layers.
SCSI provides a richer set of asynchronous operations, and has a more robust design for its shared bus.
ATA still relies on 2 channels, each shared by 2 disks, but each ATA spec improves on the one before it in terms of command-set, borrowing ideas from SCSI.
SCSI disks also tend to be more high-end, have larger track buffers on the average, which gives better data throughput. Of course all this goodnesss comes at a $$price.
I don't think either of them would really come off better in a latency measurement, because internally, they would use the same disk technology (assuming both disks under comparison have the same mechanical and low-level electronic characteristics).
Although I would love to know if this is actually the case...
What I'm saying is IDE is a mess. And what good is that machine? It works just fine without that drive. Note, it's not a floppy drive, but a CD-ROM drive that was bad and causing the problem. I didn't know it at the time, but the drive was borked.
If you don't know, IDE was only supposed to have one device per channel, and it's just a hack to have a secondary device on each channel. Furthermore, if you put two drives on one channel, and you start copying from one drive to the other, you'll notice a significant loss in performance. SCSI doesn't correct for ignorant users, but it's not as much of a mess as IDE is.
Help me. I've been modbombed by a few people with entirely too much time on their hands.
Bruce Lee in his film, the *game of death* shows that there was no *way* (al lah - way of the intercepting fist ) but I digress.
The story of Ed, was one of the first Unix editors is told by esr in his new book , The Art of Unix Programming which contains a great section on editors, A Tale of Five Editors - comparing Ed, vi, Sam, Emacs and Wily.
peterrenshaw ~ Another Scrappy Startup
I use LTO Ultrium on IBM RS/6000 hardware and if used with differential (rather then single ended) SCSI it seems to SCREAM!
First time I saw it in action we backed up 17 GB in less then 10 Min.
Restore from Tape is just about as fast.
I want one for home, but it would take lottery winnings for that kind of spending cash.
Capacity on an Ultrium 2 unit is 200GB uncompressed.
Well I've wrestled with reality for thirty five years doctor, and I'm happy to say I finally won out over it.