I've been wondering about this for a while, is there a interface (ie ata66, scsi, scsi-uw,etc) whos speed stands out versus its cost? Or are all the different formats relative.
Any thoughts?
pX
Any thoughts?
pX
HD speed vs cost
- Thread starter pX
- Start date
ATA66 is a big joke!
Current IDE drives are almost as fast a SCSI, and for anything but a server is a big waste.
Imho of course.
Current IDE drives are almost as fast a SCSI, and for anything but a server is a big waste.
Imho of course.
IMO, IDE is a way better value.. by a long shot. IDE is close to SCSI speed, but its probably half the price (i think i am prety close about the price, if not someone correct me, plez...) if you want the absolute fastest thing, go with SCSI, but for the best price/preformence value, IMO, go with a 7200 RPM IDE drive... the IBM drives are probably the fastest, but i dont really have any evedince to back that up.
- Jason
- Jason
I've been of a mind that for high performance at a reasonable cost I'd go with two IDE 7200 rpm HDD's in a RAID-0. Make sense? Beats SCSI on the cost front anyway.
Not sure about how to handle backups !
Smaller SCSI HD's (<= 9.1GB), are comparable to IDE's in price, and have excellent performance.
Low CPU utilization can make a big difference too.
Low CPU utilization can make a big difference too.
Yeah I was thinking about grabbing that buy.com 45 gig 5400 drive for storage, then have a smaller scsi (8 gigish) for my OS and such.
Oh another question, there are several types of SCSI right? What are they and what are the performance differences and price diffs?
pX
Oh another question, there are several types of SCSI right? What are they and what are the performance differences and price diffs?
pX
oh please, those interfaces mean nothing. drives are not that fast. look for rotation speeds with respect to drives.
for large drives, it's just easier to get IDE drives. I mean, SCSI varieties are faster, but the $$ is just TOO MUCH.
and with respect to speed, even a IDE in RAID 0 is cheaper than a SCSI drive and controller of the same capacity (if the capacity is large enough).
for large drives, it's just easier to get IDE drives. I mean, SCSI varieties are faster, but the $$ is just TOO MUCH.
and with respect to speed, even a IDE in RAID 0 is cheaper than a SCSI drive and controller of the same capacity (if the capacity is large enough).
You need only watch a disk defrag to lay to rest any debate that IDE RAID can compete with 10k and 15k RPM SCSI drives in anything but large file transfers like video capture, which are completely atypical for normal usage.
The ideal setup for most people who have a little extra money to spend is to get a 9GB high RPM SCSI drive as a boot/applications drive, and then go 7200RPM IDE for larger cheap storage.
SCSI has no CPU utilization advantage anymore. And before someone else mentions it, larger caches on SCSI drives are irrelevant as well.
Some people will look at the prices of SCSI and get sticker shock. It's not cheap, but it isn't nearly as bad as some people will have you believe, and once you go highend SCSI, you won't ever want to go back. You can get a 9GB Seagate Cheetah for under $200, which is not that expensive at all.
As for the interfaces, with SCSI160 cards selling for under $200, there is no reason to get anything less even though you will never need that bandwidth, or actually be able to use it for that matter.
The ideal setup for most people who have a little extra money to spend is to get a 9GB high RPM SCSI drive as a boot/applications drive, and then go 7200RPM IDE for larger cheap storage.
SCSI has no CPU utilization advantage anymore. And before someone else mentions it, larger caches on SCSI drives are irrelevant as well.
Some people will look at the prices of SCSI and get sticker shock. It's not cheap, but it isn't nearly as bad as some people will have you believe, and once you go highend SCSI, you won't ever want to go back. You can get a 9GB Seagate Cheetah for under $200, which is not that expensive at all.
As for the interfaces, with SCSI160 cards selling for under $200, there is no reason to get anything less even though you will never need that bandwidth, or actually be able to use it for that matter.
I got my 2 18Gb Cheetahs 10K very cheap, and personally I have yet to see an IDE drive that could get near them for speed. Also their access are a lot better. And could IDE handle both these drives, while both are in use along with DVD and CDR. SCSI has other advantages to with other features.
Also price wise IDE is better for most normal computing needs.
Also price wise IDE is better for most normal computing needs.
yeah, just throw those cheetah's at em
They are for two completely different markets. And raid 0 ide is no good, gotta have 4 drives, raid 5 (i think.. stripe and redundancy)
They are for two completely different markets. And raid 0 ide is no good, gotta have 4 drives, raid 5 (i think.. stripe and redundancy)
Look at RAID benchmarks. CPU utilization is still relevant, I consider up to 20% CPU utilization to be a lot. Large caches are not irrelevant either. The performance boost from them is small, but still there. Multitasking on a SCSI HD beats multitasking on IDE, hands down.
LVD or LVD 160 are both probably more than enough for most people. I'm using LVD (80MB/sec), and I don't think I ever max it out, with 2 HD's, a CD burner and a CDROM. My HD does benchmark faster on a 160 card...not sure why, it's probably just optimized for better performance since it's newer.
LVD or LVD 160 are both probably more than enough for most people. I'm using LVD (80MB/sec), and I don't think I ever max it out, with 2 HD's, a CD burner and a CDROM. My HD does benchmark faster on a 160 card...not sure why, it's probably just optimized for better performance since it's newer.
No one said CPU utilization is irrelevant. What is irrelevant is comparing it between interfaces because they are basically the same. Under light loads both will use under 5%, which is unnoticable. However, when either interface is running full bore, depending on the OS and the speed of the drive, utilization can jump up to 50%. It is a complete myth that SCSI offloads all work from the CPU, it doesn't. Run Intel's Threadmark benchmark and look at the CPU results. I myself own a Seagate Cheetah X15. When I transfer large amounts of files within the drive itself, my Dcypher.net speed drops from 25000+rays/s to 14000ray/s, which is basically exactly the same as my IDE drives. That's almost a 45% CPU hit from a SCSI drive.
If you want to see the effect of cache size on performance, cruise over to Storagereview.com. They compare a Maxtor drive with 512k cache to one with 1MB, same drive different cache sizes. The difference in performance was nil. Here's the link:
http://www.storagereview.com/articles/9906/990626Mxt5120BfrDif.html
Their conclusion was this: "A larger buffer in and of itself is no asset and makes little difference in performance."
If you want to see the effect of cache size on performance, cruise over to Storagereview.com. They compare a Maxtor drive with 512k cache to one with 1MB, same drive different cache sizes. The difference in performance was nil. Here's the link:
http://www.storagereview.com/articles/9906/990626Mxt5120BfrDif.html
Their conclusion was this: "A larger buffer in and of itself is no asset and makes little difference in performance."
Go to storage review and compare the Quantum Atlas V (awesome drive and not too expensive) to any range of ATA-66 drives, and you'll find that it comes out on top. It has twice the buffer of any of the ATA-66 drives I compared it with, but I can't say how much that affects performance.
I looked at the following drives:
IBM Deskstar 75GXP (75.0 GB ATA-66) 7200 RPM
Maxtor DiamondMax 60 (60.1 GB ATA-66) 5400 RPM
Quantum Atlas V (36.7 GB Ultra160/m SCSI) 7200 RPM
Quantum Fireball Plus LM (30.0 GB ATA-66) 7200 RPM
Seagate Barracuda ATA II (20.4 GB ATA-66) 7200 RPM
Western Digital Caviar 7200rpm (20.5 GB ATA-66) 7200 RPM
The quantum has by far the best seek time:
6.3 ms
next best is the cuda with 8.2 ms
9.0 was the worst.
As I said, the quantum came out on top in every benchmark, and all but once or twice it scored the highest IOs per CPU%
In response to your comments about CPU utilization, both promise and software RAID setups were shown to have very high CPU utilization, higher than a single IDE drive. Also, it has been my experience when burning CD's on IDE systems that you can't do much of anything else while you're burning. I have actually defragged my hard drive while burning from cd to cd, yet on an IDE system I couldn't even load netscape.
I've also heard reports of people playing UT and quake while burning, on all SCSI systems. Is there an IDE system that can do that? Why not? CPU utilization perhaps?
I looked at the following drives:
IBM Deskstar 75GXP (75.0 GB ATA-66) 7200 RPM
Maxtor DiamondMax 60 (60.1 GB ATA-66) 5400 RPM
Quantum Atlas V (36.7 GB Ultra160/m SCSI) 7200 RPM
Quantum Fireball Plus LM (30.0 GB ATA-66) 7200 RPM
Seagate Barracuda ATA II (20.4 GB ATA-66) 7200 RPM
Western Digital Caviar 7200rpm (20.5 GB ATA-66) 7200 RPM
The quantum has by far the best seek time:
6.3 ms
next best is the cuda with 8.2 ms
9.0 was the worst.
As I said, the quantum came out on top in every benchmark, and all but once or twice it scored the highest IOs per CPU%
In response to your comments about CPU utilization, both promise and software RAID setups were shown to have very high CPU utilization, higher than a single IDE drive. Also, it has been my experience when burning CD's on IDE systems that you can't do much of anything else while you're burning. I have actually defragged my hard drive while burning from cd to cd, yet on an IDE system I couldn't even load netscape.
I've also heard reports of people playing UT and quake while burning, on all SCSI systems. Is there an IDE system that can do that? Why not? CPU utilization perhaps?
Maybe someone here can explain what you are trying to prove with the first part of your post, because I sure don't get it.
Manufacturers' quoted seek times are a pretty useless stat. They are usually wrong, and they are only half the equation that adds up to access time which is what is really important. Seagate has the lowest quoted seek time, but real world performance measured by winbench shows that the Quantum LM (11.5)has a full ms advantage over the seagate drive(12.5) in access time. Both drives are 7200RPM's which means they should both have the same latency of 4.17ms. Taking this into account, the Quantum drive is actually faster than the stated manufacturer's claim while the Seagate drive is slower.
CPU% per IO is useful only for personal interest, the absolute value is what matters. No one cares how much you are getting per cycle, what the total impact on your system is what counts. In that regard, the Atlas came in last in basically every single category.
"both promise and software RAID setups were shown to have very high CPU utilization, higher than a single IDE drive"
When was the last time you saw a software anything that was faster than hardware? The Promise controller is not a true hardware RAID implementation, proven by the fact the hardware is basically identical to the standard IDE controller made by Promise.
RAID should have higher CPU% because it is streaming more data. IO/s do not increase CPU utilization, as IOMeter shows, since those are handled by the SCSI CPU/IDE controller. CPU utilization is almost soley based on how fast the drive's STR is. Take a look at the numbers again, and you will see this.
You're also wrong on the CDR issue. IDE can't multitask worth a d*** since only one device per channel can be accessed at a time. The CPU has no bearing on that. You can't do mass file moves during an IDE burn because if your IDE drive is moving files, the CDR drive can't get the required access it needs to the IDE bus. I have no idea what system setup you have, but I have never heard of anyone defragging a hard drive while burning a CD. I have a Seagate Cheetah X15 and a Plextor 8/20 CDR, and it wouldn't even cross my mind to do something that dumb.
Just to add to my post here are HD Tach results for CPU utilization of the drives in my system:
Cheetah 34.5%
WD Caviar 7200RPM 8.8%
Quantum LM+ 11%
Quantum KA+ 11.1%
Manufacturers' quoted seek times are a pretty useless stat. They are usually wrong, and they are only half the equation that adds up to access time which is what is really important. Seagate has the lowest quoted seek time, but real world performance measured by winbench shows that the Quantum LM (11.5)has a full ms advantage over the seagate drive(12.5) in access time. Both drives are 7200RPM's which means they should both have the same latency of 4.17ms. Taking this into account, the Quantum drive is actually faster than the stated manufacturer's claim while the Seagate drive is slower.
CPU% per IO is useful only for personal interest, the absolute value is what matters. No one cares how much you are getting per cycle, what the total impact on your system is what counts. In that regard, the Atlas came in last in basically every single category.
"both promise and software RAID setups were shown to have very high CPU utilization, higher than a single IDE drive"
When was the last time you saw a software anything that was faster than hardware? The Promise controller is not a true hardware RAID implementation, proven by the fact the hardware is basically identical to the standard IDE controller made by Promise.
RAID should have higher CPU% because it is streaming more data. IO/s do not increase CPU utilization, as IOMeter shows, since those are handled by the SCSI CPU/IDE controller. CPU utilization is almost soley based on how fast the drive's STR is. Take a look at the numbers again, and you will see this.
You're also wrong on the CDR issue. IDE can't multitask worth a d*** since only one device per channel can be accessed at a time. The CPU has no bearing on that. You can't do mass file moves during an IDE burn because if your IDE drive is moving files, the CDR drive can't get the required access it needs to the IDE bus. I have no idea what system setup you have, but I have never heard of anyone defragging a hard drive while burning a CD. I have a Seagate Cheetah X15 and a Plextor 8/20 CDR, and it wouldn't even cross my mind to do something that dumb.
Just to add to my post here are HD Tach results for CPU utilization of the drives in my system:
Cheetah 34.5%
WD Caviar 7200RPM 8.8%
Quantum LM+ 11%
Quantum KA+ 11.1%
You're right, quoted seek times don't always mean much, but compare the quantum to any ATA drive out there, it'll beat it out. (I own the Atlas V, BTW).
CPU% per IO is actually the most useful gauge for finding out what sort of CPU utilization you're really going to get. That way you can calculate how much CPU utilization you'll get doing 100 (or however many your program is requiring...) IO/s. And the Quantum will win, thus, lowest CPU utilization.
"When was the last time you saw a software anything that was faster than hardware?"
Actually, in the tests with the promise RAID card, I believe software did come out on top, at least in terms of CPU utilization. Weird huh?
"The Promise controller is not a true hardware RAID implementation, proven by the fact the hardware is basically identical to the standard IDE controller made by Promise."
When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI.
I have no idea what system setup you have, but I have never heard of anyone defragging a hard drive while burning a CD. I have a Seagate Cheetah X15 and a Plextor 8/20 CDR, and it wouldn't even cross my mind to do something that dumb.
There's nothing dumb about wanting to defrag your hard drive, it is beneficial for your computer. Really. Here's my main system:
IBM 18ES LVD 7200 RPM
Quantum Atlas II SE 7500 RPM
Ultraplex 40MAX
Yamaha 4416S
all SCSI, obviously. I was actually running the defrag while burning to see just how much I could do while burning, before I made a coaster. And it worked just fine.
In case you're wondering where the Atlas V went, it's in my other system, which I haven't messed with as extensively:
Quantum Atlas V LVD 160 7200 RPM
Ultraplex 40MAX
Plexwriter 8/20
You are correct about another of IDE's faults, only one device may be accessed at a time. But try getting on an IDE system, start burning and do something very processor intensive that doesn't involve the hard drive much. won't work.
I can't run HDtach in Win2k unless I want to upgrade to the full version, but when I ran it in 95, my results were much better than yours.
HDtach reported 0% CPU utilization.
HDtach isn't the most reliable or accurate benchmark anyway.
CPU% per IO is actually the most useful gauge for finding out what sort of CPU utilization you're really going to get. That way you can calculate how much CPU utilization you'll get doing 100 (or however many your program is requiring...) IO/s. And the Quantum will win, thus, lowest CPU utilization.
"When was the last time you saw a software anything that was faster than hardware?"
Actually, in the tests with the promise RAID card, I believe software did come out on top, at least in terms of CPU utilization. Weird huh?
"The Promise controller is not a true hardware RAID implementation, proven by the fact the hardware is basically identical to the standard IDE controller made by Promise."
When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI.
I have no idea what system setup you have, but I have never heard of anyone defragging a hard drive while burning a CD. I have a Seagate Cheetah X15 and a Plextor 8/20 CDR, and it wouldn't even cross my mind to do something that dumb.
There's nothing dumb about wanting to defrag your hard drive, it is beneficial for your computer. Really.
Here's my main system:IBM 18ES LVD 7200 RPM
Quantum Atlas II SE 7500 RPM
Ultraplex 40MAX
Yamaha 4416S
all SCSI, obviously. I was actually running the defrag while burning to see just how much I could do while burning, before I made a coaster. And it worked just fine.
In case you're wondering where the Atlas V went, it's in my other system, which I haven't messed with as extensively:
Quantum Atlas V LVD 160 7200 RPM
Ultraplex 40MAX
Plexwriter 8/20
You are correct about another of IDE's faults, only one device may be accessed at a time. But try getting on an IDE system, start burning and do something very processor intensive that doesn't involve the hard drive much. won't work.
I can't run HDtach in Win2k unless I want to upgrade to the full version, but when I ran it in 95, my results were much better than yours.
HDtach reported 0% CPU utilization.
HDtach isn't the most reliable or accurate benchmark anyway.
<< I consider up to 20% CPU utilization to be a lot >>
That is extremely relevant. My 20GB 7200rpm Quantum takes 99.5 - 99.9% of my CPU (P83). Although my old seagates take about 45%, the Quantum is superfast compared to them.
And yes, SCSI is WAY faster than IDE. Not just a little bit - plus the access time makes a huge difference as well... if it didn't cost so damn much, I wouldn't mind havin some SCSI power
That is extremely relevant. My 20GB 7200rpm Quantum takes 99.5 - 99.9% of my CPU (P83). Although my old seagates take about 45%, the Quantum is superfast compared to them.
And yes, SCSI is WAY faster than IDE. Not just a little bit - plus the access time makes a huge difference as well... if it didn't cost so damn much, I wouldn't mind havin some SCSI power
"but compare the quantum to any ATA drive out there, it'll beat it out"
Yes, that's true, but I'm missing the point you are trying to make.
"That way you can calculate how much CPU utilization you'll get doing 100 (or however many your program is requiring...) IO/s"
IOMeter is simply a glorified access time benchmark. I/O's do not tax the CPU, which is what IOMeter is testing, sustained transfers do, which basically makes your arguement, though sound in reasoning, incorrect.
"Actually, in the tests with the promise RAID card, I believe software did come out on top, at least in terms of CPU utilization. Weird huh?
It's not weird because the Promise controller is not a hardware implementation. It's an IDE controller with a different BIOS and a crappy software driver.
"When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI."
That doesn't negate the fact it isn't a very good product. The Promise controller brought RAID to an audience that knows very little about it. They see the word RAID and think that this product will turn their PC in to some highend server of something, and it won't. You get what you pay for.
I understand the benefits of defragging, I'm just not going to do it when I am burning a CD.
"You are correct about another of IDE's faults, only one device may be accessed at a time. But try getting on an IDE system, start burning and do something very processor intensive that doesn't involve the hard drive much. won't work."
I used to have an IDE HP CDRW. I could run Seti and do basic websurfing and what not without a problem while burning a cd. It's vital that you enable DMA on your CDR drive, it will alleviate a number of problems.
"HDtach reported 0% CPU utilization."
Run any disk intensive application and the performance penalty on your system will make it obvious that 0% CPU utilization is not accurate. Your SCSI drives are also really slow (not the Atlas, the other 2) by SCSI standards and not an accurate representation of how a 10k or 15k rpm drive would perform.
"HDtach isn't the most reliable or accurate benchmark anyway."
It's lowlevel results, access time and STR, are right in line with Winbench's numbers. It's far far more reliable than the Sandra numbers people love to post all the time.
There's something wrong with your configuration RSI. No drive should be taking that much CPU time. Make sure DMA is enabled. Though judging by the age of your system, that may no be possible.
IDE definitely wins the bang for buck contest.
Yes, that's true, but I'm missing the point you are trying to make.
"That way you can calculate how much CPU utilization you'll get doing 100 (or however many your program is requiring...) IO/s"
IOMeter is simply a glorified access time benchmark. I/O's do not tax the CPU, which is what IOMeter is testing, sustained transfers do, which basically makes your arguement, though sound in reasoning, incorrect.
"Actually, in the tests with the promise RAID card, I believe software did come out on top, at least in terms of CPU utilization. Weird huh?
It's not weird because the Promise controller is not a hardware implementation. It's an IDE controller with a different BIOS and a crappy software driver.
"When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI."
That doesn't negate the fact it isn't a very good product. The Promise controller brought RAID to an audience that knows very little about it. They see the word RAID and think that this product will turn their PC in to some highend server of something, and it won't. You get what you pay for.
I understand the benefits of defragging, I'm just not going to do it when I am burning a CD.
"You are correct about another of IDE's faults, only one device may be accessed at a time. But try getting on an IDE system, start burning and do something very processor intensive that doesn't involve the hard drive much. won't work."
I used to have an IDE HP CDRW. I could run Seti and do basic websurfing and what not without a problem while burning a cd. It's vital that you enable DMA on your CDR drive, it will alleviate a number of problems.
"HDtach reported 0% CPU utilization."
Run any disk intensive application and the performance penalty on your system will make it obvious that 0% CPU utilization is not accurate. Your SCSI drives are also really slow (not the Atlas, the other 2) by SCSI standards and not an accurate representation of how a 10k or 15k rpm drive would perform.
"HDtach isn't the most reliable or accurate benchmark anyway."
It's lowlevel results, access time and STR, are right in line with Winbench's numbers. It's far far more reliable than the Sandra numbers people love to post all the time.
There's something wrong with your configuration RSI. No drive should be taking that much CPU time. Make sure DMA is enabled. Though judging by the age of your system, that may no be possible.
IDE definitely wins the bang for buck contest.
"but compare the quantum to any ATA drive out there, it'll beat it out"
Yes, that's true, but I'm missing the point you are trying to make.
The point I'm making is that ATA drives are not up to SCSI speeds, there is still a significant performance difference.
IOMeter is simply a glorified access time benchmark. I/O's do not tax the CPU, which is what IOMeter is testing, sustained transfers do, which basically makes your arguement, though sound in reasoning, incorrect.
Alright. I was just using storagereview since you had quoted rom them, but apparently they don't have anything on their site which really gives an accurate guage of CPU utilization.
"When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI."
That doesn't negate the fact it isn't a very good product.
I agree! My point was to those who suggets an IDE RAID as being cheaper with comparable performance to SCSI. Not true with the promise card because it's not very good, and if you get an expensive IDE RAID card, you're probably looking at more expensive than SCSI, not less.
The Promise controller brought RAID to an audience that knows very little about it. They see the word RAID and think that this product will turn their PC in to some highend server of something, and it won't. You get what you pay for.
Exactly. You buy a cheap IDE hard drive, you get cheap performance. Spend a little extra on SCSI, get extra performance.
I understand the benefits of defragging, I'm just not going to do it when I am burning a CD.
There's no reason not to if your HD needs a defrag and your system can handle it...why wait? I like the SCSI set up becaues I can do just about anything I want with my system while I'm burning, so long as I don't reboot.
I used to have an IDE HP CDRW. I could run Seti and do basic websurfing and what not without a problem while burning a cd. It's vital that you enable DMA on your CDR drive, it will alleviate a number of problems.
As I do'nt have erady access to an IDE system with a burner, I can't tweak it out and test it, but the ones I used had major problems if you did anything else with them while they were burning.
Run any disk intensive application and the performance penalty on your system will make it obvious that 0% CPU utilization is not accurate.
I agree that 0% CPU utilization is not accurate, but I'm sure it is very low. Again, I can defrag a HD, run netscape, ICQ, and play MP3's at the same time, and if I defrag the HD I'm not using, there is little performance loss, the worst part is that I have to turn up my MP3 player to drown out the sound of the HD grinding away.
Your SCSI drives are also really slow (not the Atlas, the other 2) by SCSI standards and not an accurate representation of how a 10k or 15k rpm drive would perform.
So? A 10k or 15k would only perform better. The Atlas II is a slow drive on a slow interface, but I got it dirt cheap and I use it for MP3 storage. The IBM is not far behind the Atlas V.
It's lowlevel results, access time and STR, are right in line with Winbench's numbers. It's far far more reliable than the Sandra numbers people love to post all the time.
Sisoft is awful, HDtach isn't bad but it obviously has some faults (the 0% CPU util thing). Though I had a very old IDE drive (couldn't enable DMA), got about 80% CPU utilization, on the same system.
Yes, that's true, but I'm missing the point you are trying to make.
The point I'm making is that ATA drives are not up to SCSI speeds, there is still a significant performance difference.
IOMeter is simply a glorified access time benchmark. I/O's do not tax the CPU, which is what IOMeter is testing, sustained transfers do, which basically makes your arguement, though sound in reasoning, incorrect.
Alright. I was just using storagereview since you had quoted rom them, but apparently they don't have anything on their site which really gives an accurate guage of CPU utilization.
"When people suggest an IDE raid setup this is the card they're usually recommending because it's cheap. If you move up to a better RAID card it becomes less cost effective as compared to going SCSI."
That doesn't negate the fact it isn't a very good product.
I agree! My point was to those who suggets an IDE RAID as being cheaper with comparable performance to SCSI. Not true with the promise card because it's not very good, and if you get an expensive IDE RAID card, you're probably looking at more expensive than SCSI, not less.
The Promise controller brought RAID to an audience that knows very little about it. They see the word RAID and think that this product will turn their PC in to some highend server of something, and it won't. You get what you pay for.
Exactly. You buy a cheap IDE hard drive, you get cheap performance. Spend a little extra on SCSI, get extra performance.
I understand the benefits of defragging, I'm just not going to do it when I am burning a CD.
There's no reason not to if your HD needs a defrag and your system can handle it...why wait? I like the SCSI set up becaues I can do just about anything I want with my system while I'm burning, so long as I don't reboot.
I used to have an IDE HP CDRW. I could run Seti and do basic websurfing and what not without a problem while burning a cd. It's vital that you enable DMA on your CDR drive, it will alleviate a number of problems.
As I do'nt have erady access to an IDE system with a burner, I can't tweak it out and test it, but the ones I used had major problems if you did anything else with them while they were burning.
Run any disk intensive application and the performance penalty on your system will make it obvious that 0% CPU utilization is not accurate.
I agree that 0% CPU utilization is not accurate, but I'm sure it is very low. Again, I can defrag a HD, run netscape, ICQ, and play MP3's at the same time, and if I defrag the HD I'm not using, there is little performance loss, the worst part is that I have to turn up my MP3 player to drown out the sound of the HD grinding away.
Your SCSI drives are also really slow (not the Atlas, the other 2) by SCSI standards and not an accurate representation of how a 10k or 15k rpm drive would perform.
So? A 10k or 15k would only perform better. The Atlas II is a slow drive on a slow interface, but I got it dirt cheap and I use it for MP3 storage. The IBM is not far behind the Atlas V.
It's lowlevel results, access time and STR, are right in line with Winbench's numbers. It's far far more reliable than the Sandra numbers people love to post all the time.
Sisoft is awful, HDtach isn't bad but it obviously has some faults (the 0% CPU util thing). Though I had a very old IDE drive (couldn't enable DMA), got about 80% CPU utilization, on the same system.
I agree with basically everything you said except for a couple of points. Using one drive, in this case the Quantum Atlas V to make a blanket statement that IDE cannot perform up to the standards of SCSI is not particularly accurate. IDE may not be able to compete with that one drive, but the Atlas V is probably the fastest SCSI 7200 drive out. IDE will equal if not beat practically every other SCSI 7200 drive. Also, I doubt that the average user doing typical tasks would ever notice the difference between an Atlas V and LM+ if it wasn't brought to their attention, which flys in the face of a "significant performance difference". I myself would definitely go for an Atlas at this point over an IDE drive, but for people who aren't that paranoid about performance, the difference does not justify the cost increase, especially on higher capacity drives.
Storagereview, which is undoubtedly the best storage site on the web doesn't have any accurate CPU measurements because there aren't any accurate and consistent ways to measure it. Winbench gives numbers under 1% while Adaptec threadmark will hit almost 60% (Atlas V gets 56.5% in win98, 43.5 in NT) for some drives. Threadmark is probably measuring worst case scenario, where typical usage will fall a bit below that. As stated earlier, you can test yourself by running any sort of distributed computing program and then copying files within the drive, note the hit in performance you get.
"So? A 10k or 15k would only perform better. The Atlas II is a slow drive on a slow interface, but I got it dirt cheap and I use it for MP3 storage. The IBM is not far behind the Atlas V."
No doubt they would perform better. My point was that they would incur a greater penalty on the CPU due to the fact they can move data so much faster than those older drives.
Storagereview, which is undoubtedly the best storage site on the web doesn't have any accurate CPU measurements because there aren't any accurate and consistent ways to measure it. Winbench gives numbers under 1% while Adaptec threadmark will hit almost 60% (Atlas V gets 56.5% in win98, 43.5 in NT) for some drives. Threadmark is probably measuring worst case scenario, where typical usage will fall a bit below that. As stated earlier, you can test yourself by running any sort of distributed computing program and then copying files within the drive, note the hit in performance you get.
"So? A 10k or 15k would only perform better. The Atlas II is a slow drive on a slow interface, but I got it dirt cheap and I use it for MP3 storage. The IBM is not far behind the Atlas V."
No doubt they would perform better. My point was that they would incur a greater penalty on the CPU due to the fact they can move data so much faster than those older drives.
I chose the atlas V because the 9.1 GB is cheap, at least I got it for cheap. Costs the same as my 18ES. If we're talking price/performance, why not use a great performing SCSI drive to compare all IDE drives too, as long as it's cheap?
Also I just compared the Atlas V with a random bunch of SCSI drives at storagereview, and it got creamed. some of them were 10k and 15kRPM drives but it even lost to the 7200RPM drives occasionally. So it's not the fastest drive out there either.
Ran the test 3 times:
Nothing copying:
[Jul 17 03:01:22 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.14 [1,234,344.76 keys/sec]
..
start benchmark and then start copying:
[Jul 17 03:02:00 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.17 [1,231,959.55 keys/sec]
..
still copying so start benchmark again:
[Jul 17 03:02:33 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.64 [1,260,269.97 keys/sec]
This is a PIII450. No performance hit shown, but I don't see why you think this is an accurate test, since when benchmarking, the RC5 program gives itself highest priority (enough to interrupt my MP3s playing)
Copied 130MB woth of MP3's between two drives (accessing both drives at the same time would only cause higher CPU utilization right?
Also I just compared the Atlas V with a random bunch of SCSI drives at storagereview, and it got creamed. some of them were 10k and 15kRPM drives but it even lost to the 7200RPM drives occasionally. So it's not the fastest drive out there either.
Ran the test 3 times:
Nothing copying:
[Jul 17 03:01:22 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.14 [1,234,344.76 keys/sec]
..
start benchmark and then start copying:
[Jul 17 03:02:00 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.17 [1,231,959.55 keys/sec]
..
still copying so start benchmark again:
[Jul 17 03:02:33 UTC] Benchmark for RC5 core #2 (RG class 6)
0.00:00:16.64 [1,260,269.97 keys/sec]
This is a PIII450. No performance hit shown, but I don't see why you think this is an accurate test, since when benchmarking, the RC5 program gives itself highest priority (enough to interrupt my MP3s playing)
Copied 130MB woth of MP3's between two drives (accessing both drives at the same time would only cause higher CPU utilization right?
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter