Sign in to follow this  
imtim83

Can any IDE HD do heavy multiple things at once?

Recommended Posts

Can any IDE HD burn a cd, zip 4 files, download a 100MB file, install 3 big games, and play a game all at the same time without a slow down in anything?

Share this post


Link to post
Share on other sites

Mercutio well what about the Seagate 3.9 ms seek time, 15000 rpm, 18 gig SCSI HD ? Can it do all of that without a noticeable slow down or no slow down ? I know i only said ide before but wondering about this SCSI HD if it could.

Share this post


Link to post
Share on other sites

Well i was just wondering plus you could have demo games you downloaded on your HD which you install the games from. I never said if the games were on cd or not.

Share this post


Link to post
Share on other sites

i also like to do a lot of stuff at once. i mean i seen people run a lot of stuff at once and never even thought it was possible. I mean 20 startup icons, 50 desktop icons, 20 + programs open, decoding, etc

Share this post


Link to post
Share on other sites

Let me repeat: No drive can do six things at once without slowing down.

If you were installing your big apps, downloading, burning a CD and zipping your files each on a different disk on a SCSI bus, no, there wouldn't be a per disk slowdown.

Hard disks are the biggest bottleneck on a computer.

Share this post


Link to post
Share on other sites
Guest russofris
i also like to do a lot of stuff at once. i mean i seen people run a lot of stuff at once and never even thought it was possible. I mean 20 startup icons, 50 desktop icons,  20 + programs open,  decoding, etc

Considering that using zip compression alone maxes out the capability of the drive....... The answer would be ......no

Long answer with practical example:

Take a 300MB file. Start zipping it. While it is zipping, look at your CPU utilization. Mine sits at 50-60% on an A1200x100. This means (to me at least) that the HDD cannot supply data to the processor as fast as the processor can zip the file.

If I zip from a source to a destination drive, the process takes about 5 seconds instead of the 8-9 that it took with a single drive. The CPU utilization maxes between 80-90%.

I have 2 WD120's. Since the STR is 50MB/s, I can deduce that an athlon 1200x100 can zip at an approximate rate of 55-60MB/sec

Sound about right?

Frank Russo

Disclaimer: This explanation in no way reflects real world performance. Mileage may vary. My math is also prone to error, as is my reasoning. I am also known to flat out lie to justify my arguments. This disclaimer is provided without meat. Four score and seven years ago our forefathers. And by my example make my school and my community a model one for safety.

Share this post


Link to post
Share on other sites

So, on a related question, is the improved performance of the typical SCSI drive over the typical IDE drive due to the interface differences or to the design differences, such as lower seek times, latency, larger cache, etc, etc?

Or perhaps it's a combination of both?

I'd be very interested in someone had two identical drives in mechanical design, firmware, etc, etc, with only the interface being different. You could then argue that any differences in performance are due to the SCSI interface itself. But with the SCSI and IDE markets so radically different, it's hard to answer this question (at least, in my mind it is ;) )

Share this post


Link to post
Share on other sites

Quantum once had their Fireball lineup in both IDE and SCSI versions. The SCSI version were of course more expensive but performed a lot worse than the IDE versions.

If this means that the IDE interface is better than SCSI given equal drives, I don't know.

Regarding the original post, SCSI would make a big difference, since it would be possible for the drive to handle multiple requests almost at the same time, where IDE drives would have to wait for one request to complete, before starting on the next one.

I guess the difference was bigger in the old days though :?

Rgds,

Mikael

Share this post


Link to post
Share on other sites
...is the improved performance of the typical SCSI drive over the typical IDE drive due to the interface differences or to the design differences, such as lower seek times, latency, larger cache, etc, etc?

For single device only - the drive's hardware is the decisive factor. As Mikael mentioned, Quantum had several drives with either identical or very close mechanics for both SCSI and IDE versions. They performed on par, except perhaps in case of Fireball SE (SCSI version of which I used to own, got it for free together with some SIIG controller ;) ) which had such a clumsy SCSI logic implementation that IDE version was faster!

The reason you keep seeing "fast" SCSI drives with IDE drives lagging behind (in RPMs, seek times, STR) is that traditionally SCSI drives are substantially more expensive, which allows to use higher RPM motors, precision heads mechanics, put larger caches on them, etc. On the downside - insofar achieving high performance on high-density platters proved problematic, so your 73GB SCSI drives are usually done in "tall" form factor (1.6" ?) - to accomodate the ungodly amount of platters (7? 8?), and you keep seing platters of around 9GB capacity in SCSI drives, while IDE drives are now shipping with 40GB/p.

The interface kicks in largely when you want to use multiple drives. At the moment, ATA is limited to one active device per channel, while Ultra160 can easily haul 3-5 drives per channel without too much of a bottleneck. With SerialATA things should improve, as each channel will only be designed to talk to one device while having very low pincount (2? he-he), so given 8-channel controllers (I wish!) built into S/Bs you'll probably see the gap between SCSI and IDE getting narrower, perhaps even 10k RPM drives appearing.

Share this post


Link to post
Share on other sites

Helldiver, good to see that you too are spreading the word! Just one small thing - there is a trailing comma or some-such in the link in your sig, so clicking it generates an error 404 and an automatic redirection to my site's index.html. Which generates some nice traffic for my incredibly out of date web page, no doubt, but doesn't help the SR emergency link thingie much.

Share this post


Link to post
Share on other sites
The reason you keep seeing "fast" SCSI drives with IDE drives lagging behind (in RPMs, seek times, STR) is that traditionally SCSI drives are substantially more expensive, which allows to use higher RPM motors, precision heads mechanics, put larger caches on them, etc. On the downside - insofar achieving high performance on high-density platters proved problematic, so your 73GB SCSI drives are usually done in "tall" form factor (1.6" ?) - to accomodate the ungodly amount of platters (7? 8?), and you keep seing platters of around 9GB capacity in SCSI drives, while IDE drives are now shipping with 40GB/p.

Part of the reason SCSI has lower areal density per platter is they use smaller disks. I think going from 3.5 inch media to 2.5 inch media means you have half the total area, so even if SCSI drives used the same areal density as IDE drives, they'd max out with 20 GB/platter. Consider they may destroke on top of everything, they end up further decreasing density. Plus, the faster you spin, the lower the density you can handle.

From a marketing standpoint, there is less incentive to increase density on SCSI drives, mainly because with the typical RAID/server situation, you want to maximize the number of spindles for redundancy.

Share this post


Link to post
Share on other sites
...so even if SCSI drives used the same areal density as IDE drives, they'd max out with 20 GB/platter.

Perhaps I should have said "high capacity platters" instead of "high density platters". Though at the moment I'm away from any useful references regarding GB/inch^2 on SCSI vs IDE, so it may well be that it's density too - I wouldn't be surprised if achieving higher heads agility (thus lower seek times) on higher density platters would be more difficult (more stringent requirements on head positioning).

From a marketing standpoint, there is less incentive to increase density on SCSI drives, mainly because with the typical RAID/server situation, you want to maximize the number of spindles for redundancy.

Up to a certain degree only - building a high performance SCSI/FC storage system of high capacity (hundreds of GBs up to TBs) is a pain in the butt, and the endeavor will eventually end up as a 19" rack full of drives. At that point you'll hit the heat, noise, maintainability difficulties, and since you'd prolly want your array mirrored anyway - having to buy more spindles. And performance-wise, having 40 SCSI drives (effective, not counting parity/mirrors) in an array will prolly not provide give you STR any higher than 20 drives as your FC-AL is maxed out at 100/200MB/s (and FC is what you're likely to use to connect your massive storage to your computing resources today). Even dual FCs won't be able to utilize the peak transfer rates of such huge RAIDed arrays. Don't you agree?

But yes, generally speaking I think such massive multi-TB storage installations represent only a realtively small fraction of SCSI drives usage worldwide, so yes, I think there is less incentive to increase per-platter capacities... Especially as it may potentially mean decreasing profit margins... ;)

Share this post


Link to post
Share on other sites

One thing that is important to remember about RAID arrays is that the more drives you use, the lower the MTBF becomes.

Assuming all drives have the same individual MTBF, the appx MTBF of a RAID array of x drives is:

( 1 / x) * MTBF of drive

I say approximate because this doesn't include the MTBF of the controller or any other components, of course.

Share this post


Link to post
Share on other sites

Can any IDE HD burn a cd, zip 4 files, download a 100MB file, install 3 big games, and play a game all at the same time without a slow down in anything?

--------------

provided that your CPU doesn't slow down, ... holding all other variables constant... no chance in hell....

you may want to consider SCSI... I have done some hard work on SCSI Cheetah's and they get their butt's worked out, but the CPU never crawls over 4 percent load... all the work is done on the scsi card... so it would then give your cpu the ability to do other tasks like play a game while the harddrives are busy copying or whatever..

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this