Building a new system: SCSI or IDE?

[Joshua P. Hill]

Pity about the price of IDE, salesfool.

And you, I suppose, are one of the foremost names in mathematical
physics?

Usual salesfool liar.

Why don't you tell your uncle again how you proved that
defragmentation was useless, dear? I'm sure he will be /very/
interested.

You obviously flogged used cars previously.

And you rather obviously do that now.

Josh

 

[Folkert Rienstra]

Mindless hairsplitting. Of course it doesn't, on the bus that is.
But that is not the point. Point is that they can be set to work simulta-
niously and split the available bandwidth between them, using that bus.

Of course it does. But so does ATA.

Gee, you don't say.

Mindlessly superficial.
That never happens on a computer as it too works in a serial fashion.

Of course it is, in a multiuser/multitasking environment.

And why ATA uses 133 MB/s to attach HDs which
have STRs of less than half of the bus data rate.

Nope. Totally to the point.

Nope.

Nor is disconnect/reconnect, known as "command overlap" in ATA,
without which Queueing in ATA would not even be possible, obviously.

Gee, how it suddenly forgets that in the next line

They don't transfer at the exact same moment either as the PCI bus
handles them in a serial fashion.

Nor if they were on seperate buses.

All controllers at some point sit on a single bus.
No OS can achieve simultaneous data transfer, period.
When 'simultanious' is used, 'virtually simultanious' is meant.

Take two Tums and call me in the morning, Rod.

The fact that you did not really disagree

Just the usual mindless silly stuff that it always spouts.

with anything I wrote only shows that both you and I know how the
traditional SCSI bus works.

How any bus works.

 

[Papa]

.... or the beta versus vhs tape format debate. Beta was considered better,
but vhs is still here.

 

[Rod Speed]

Some silly little pathological liar claiming to be
Joshua P. Hill <[email protected]> desperately
attempted to bullshit its way out of its predicament in message
and fooled absolutely no one at all. As always.

 

[Rod Speed]

Rod Speed wrote

Take two Tums and call me in the morning, Rod.

Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

The fact that you did not really disagree with anything I wrote

More of your lies.

only shows that both you and I know
how the traditional SCSI bus works.

Pity you made such a spectacular fool
of yourself with your original silly claim.

The ONLY thing that works in that particular situation
is to keep your silly trap shut and hope everyone
forgets about your stupidity as quickly as possible.

 

[Rod Speed]

Some silly little pathological liar claiming to be
Joshua P. Hill <[email protected]> desperately
attempted to bullshit its way out of its predicament in message
and fooled absolutely no one at all. As always.

 

[John Yuen]

If you plan on no more than 4 HDs, look at the Antec Sonata Quiet Case
with rubber isolation mounts for HDs.

Regards
John Yuen

 

[troll shafter]

Some pathetic excuse for a troll claiming to be
Folkert Rienstra <[email protected]>
mindlessly trolled away like mad in message
and fooled absolutely no one at all. As always.

 

[Bowser]

I'm running XP Pro, SP-1. The performance is excellent, and I have used a
Quantum 10K SCSI LVD drive in the past. Like many, when I "upgraded" from
Win 2000 to XP, the performance of my SCSI drive went to hell. The drivers
for the Adaptec 19160 board never materialized (they may have since then),
so I switched to other solutions. I'll run any disk performance tests you'd
like, and post the results. Let me know which measuring tool is best.

 

[Bowser]

Thanks you so much for assuming I work for a storage company. I don't. I
mentioned the drives so readers would have a frame of reference. I mentioned
my opinion of their performance. Check any of the techie sites and see if
I'm lying, or if this is hype. I suppose you can prove that the RAID 0 array
I'm running isn't faster than a single drive solution?

Please do me a favor, and drop dead.

 

[Folkert Rienstra]

You didn't list any AV drives there.

Neither did you correct that. And we both know why, don't we.

So you admit that you were wrong:
"But SCSI has traditionally been a lot faster"

If you wanted performance, they were the drives you got.

AV drives have nothing to do with raw STR.
AV drives were selected drives from existing ranges that were selected
for bad blocks not to interrupt continuous transfer (streaming). They we-
re not any faster. Some AV drives were shortstroked (capacity reduced)
so that their specs would appear better because of a better lowest STR
in comparison to their full size brothers providing a better average STR.

The same thing could be done to ATA drives as well except for one
feature that SCSI has had all along but ATA didn't: reduce/disable
retry counts or disable error correction. The latter of course made
them pure AV drives, unfit for holding data reliably.

Nope, I never said SCSI had better sustained transfer rate.

Yes, you did: "But SCSI has traditionally been a lot faster"

I said that if
you were just after sustained transfer rate that I thought you were better
off going with IDE RAID, and possibly getting more drives, because it will
be cheaper than going SCSI and provide better perfromace.


Why is that cheating? If you want a high sustained transfer rate you would
go with RAID.

Exactly what I said with SCSI and you then questioned that as if I were cheating.

but they are a lot more expensive.

Never said it did.

Yes you did: "why not get a bit more performance".

You should have read my very next line that clearly stated "That's for throughput".

Yes, and? So what is your alternative for reduced access time in IDE?

I completely disagree. Firstly, we are only talking about one subsystem
here. It is commonly agreed that in order for an end user to actually notice
a speed difference in their machine, they need about a 10-15% overall system
speed increase.

Well, that's easy. Reduce latency and cpu performance goes up as well.
When the system is waiting for the disk subsystem, it has to idle, reducing
overall performance significantly.

A faster access time won't make anywhere near a 10% difference

Storage Review doesn't agree with you, 10% is about the minimum difference
between SCSI and ATA in their desktop benchmarks except for the highend
one where some Caviar closes up the gap somewhat.
http://www.storagereview.com/articles/200111/20011109Renaissance_7.html

If you go to IO/s, SCSI wins with a 100% margin.
http://www.storagereview.com/articles/200111/20011109Renaissance_8.html

even in the hard disk subsystem, not to mention overall difference.

Actually when you improve the one, the other improves as well.
When the system is waiting for the harddrive the system is idle.
The sooner the harddrive responds the system can continue.
The less idle, the better the performance.

Given that SCSI drives are substantially more expensive, that's
a lot of money to pay for something un-noticable.

So, where went 'secondly'?

You just like to argue, don't you?

Typical.
I proved you wrong on that ATA being behind a lot previously and you come
up with AV and you dare accuse me of liking to argue. Stop trolling, Church.
I was correct and you are the one arguing.

Personally, if I was installing a server
that was vital to a business, I would use SCSI, because I consider it to be
more reliable. Even in a less-vital server if I did decide to use IDE, I
would replace the drives after 2 or 3 years (retire them to a less important
role in a client machine). Given that you are advocating SCSI for use in a
desktop machine, I find it strange that you don't consider it to be more
robust. Why is it you are advocating it?

Surely not just for the slightly better access time?

No? What exactly did you not understand?

I'm not sure which misconception you are referring to.

Of course you don't: "But SCSI has traditionally been a lot faster"

We are talking about IDE vs SCSI here, talking about how
other components have improved over time is not of relevance.

Actually, that was your whole point:

"Saying all components have improved over time is kinda obvious, what
we are discussing here is their improvements comparative to one another".

Problem is, you are changing your point every time I debunk it.

Of course it is, but he should make an informed decision. I think SCSI would
be a complete waste of money in this situation, and have given reasons why I
think that.

No, you haven't, other than unsubstanciated and debunked claims. Even next
you inversively claim that there were reasons to use SCSI in Desktop systems.
The only reason for that must have been access times as I have proven that STR
couldn't have been. Now you claim that those same reasons can't be valid anymore.

So you agree?

I guess that depends on what you consider a workstation to be. I would
define it more by what it is used for (like high-end graphics and CAD work),
than what it's hardware is.

Bingo. Are you 'arguing' that the two don't go together?

No matter what your definition is, there is a very clear trend away from
SCSI in workstation and low-end servers in favour of IDE.


Well, it depends on what you mean by that.

Obviously "for multitasking since it doesn't share a channel anymore".

At the moment no drives' sustained data rate come anywhere
near SATA's theoretical peak (150 megabytes per second).

Of course it doesn't. It would be immediately obsolete if it did.

Most drives can write at about 30 megabytes per
second, and read at about 50. ATA66 is fast enough for that (and ATA33
is fast enough for the writes). There is a small advantage when using the
drives buffer, but that makes a fairly insignificant difference overall.

Sigh! You just don't get it, do you?
ATA is a 2 device bus, devices have to share the bandwidth.
With drives doing in the 60MB/s currently ATA133 barely copes.

At the moment, the benefits of SATA are the cables. No more wide cable
that is difficult to move around, and bad for air flow within the case. No
more worrying about master and slave jumper settings. And of course you
are future-proofing your system (although personally I don't see much point
in doing that).


Although a lot has been made of it, that was never a significant problem.

Not if you don't value multitasking performance, no. Or don't mind buying
an extra add-in controller to avoid the one drive at a time bottleneck.

That is one more advantage of SATA - no more newsgroup posts asking
what the optimal configuration of their drives is.


Then why would SAS only be used in servers and the like?
Why wouldn't SATA take over these areas,

Because you can use a lot more of them than you can SATA.

if they are just the same drives?

Obviously they aren't, with different firmware.
But being the same mechanism and electronics they can be build cheaper.

 

[Gareth Church]

... or the beta versus vhs tape format debate. Beta was considered better,
but vhs is still here.

Yep, that's another favourite in the Mac vs PC debates. It's an interesting
logic - Beta was superior and it wasn't as popular as VHS. Macs aren't as
popular as PCs, therefore Macs are superior. I suppose with the premium they
pay for theirs machines they have to justify it somehow, even if it is as
ridiculous as that argument.

Gareth

 

[chrisv]

A quick analogy for you:

IDE 4 cylinder. SCSI V8.

They both do the same job, but you know that the SCSI will go on for ever,
and not wear itself out.

Simon

Only a moronic top poster could come up with such a stupid, wrong,
analogy.

 

[J.Clarke]

Well the Seagate Cheetah are now rated at 3.1DB at idel while their
SATA
are rated at 2.5DB.

The smallest Cheetahs X15s are rated 3.1 Bels, not DB. The 73 gig X15s
are rated at 3.5. The 7200.7 is rated "< 2.5" Bels for the 80 gig and
smaller and 2.5 for the larger sizes. In both cases those are at idle.
With acoustic management on the noise level during seek for the 7200.7
goes up to 2.5 for the smaller drives and 2.8 for the larger. Seagate
does not specify a noise level for the Cheetahs during seek--the ones
that I have used have been clearly audible 20 feet away behind a
partition.

I would not use an X15 in a machine that had to be quiet.

I would say that's pretty good for a drive
spinning at twice the speed.

The problem is that it's not all that good in an absolute sense.

I have the 120Gb Seagate SATA and during
normal operations, they are much quieter than the IBM 80GB 7200rpm in
my last system. I would say that the 60GB 5400rpm on my laptop is more
noticable in operation than the Seagate.

The IDE Barracudas are the quietest drives on the market so this is to
be expected.

 

[John Yuen]

Well the Seagate Cheetah are now rated at 3.1DB at idel while their SATA
are rated at 2.5DB. I would say that's pretty good for a drive spinning at
twice the speed. I have the 120Gb Seagate SATA and during normal
operations, they are much quieter than the IBM 80GB 7200rpm in my last
system. I would say that the 60GB 5400rpm on my laptop is more noticable
in operation than the Seagate.

Regards
John Yuen

 

[Folkert Rienstra]

I'm really unsure how you came to this conclusion.

Yes, I don't know that either, with my table conveniently snipped.
You just have no shame, have you, Church, playing dumb.

My memory isn't good enough to remember STRs for a number of drives
from yesteryear. it is good enough to remember that when I compared

top-end SCSI and top-end IDE drives

Typical how you again fail to name them so that we cannot check you up
on that.

in the past the SCSI drives were almost always faster.

"Almost always". Or in other words 'slightly faster'.

Traditionally new
features and improvements were made to SCSI first (because that was were
the money was to be made). If they worked, they were later added to IDE.

We are not talking about features, we are talking about that
stupid claim of yours: "SCSI has traditionally been 'a lot' faster".

And I forgot: recalibrates not interrupting transfers.

We're not talking about data reliability here, we are talking about performance.
Whether or not getting that performance has affects reliability is not at issue.

So what? They were not any faster, period.
Do you have a point or are you arguing for argument sake here, Church?
Since you don't come up with evidence of the contrary I again have to
conclude that you came up once with another false argument again of
"SCSI has traditionally been 'a lot' faster".

By taking comments out of their context you are giving an unclear picture.
SCSI has been traditionally faster than IDE.

Nope, you obviously just changed your position, again.

We have now gone from 'a lot faster' to just 'faster'.
Which is in keeping with my findings with the 1997 results where SCSI
has the same or very slightly better STRs than IDE, nothing to brag about.
If anything, SCSI is slightly faster currently in the latest 15k rpm drives.
The Maxtor Plus 8 comes very close and that is already an older IDE drive.

When I said that we were talking about single

drives of the past (hence the word traditionally).

Wordgames. Correction: stupid wordgames.

That statement still stands true and I stick by it.

Fool you.

The snippet above follows on from a discussion about RAID.
In that I said that now IDE RAID is available, you can get a better
sustained transfer rate using IDE drives (by adding more drives),
and still save money over SCSI. That statement, too, still stands true
and I stick by that.

Irrelevant to your claim that "SCSI has traditionally been 'a lot' faster".

You've lost me I'm afraid.

Of course you do. And don't we all know why.

What exactly did you say about SCSI, and how did I imply you were 'cheating'?


You can take quotes out of context all you like and pretend I was referring
to something else, but it doesn't change reality. I said "why not get a bit
more performance" in regards to sustained transfer rate, after talking about
RAID. Never did I suggest IDE had better access times.

Exactly. So you used the word performance totally out of context.

STR is worthless with small IO. RAID is worthless with small IO.
To talk of performance in that context falls just short of criminality.

I wasn't talking about access times.

Bingo. You should have.

That's the whole point.

Bingo again. The whole 'missing' point.

I said you can get better performance from IDE RAID (over SCSI RAID,
by using more IDE drives). I then very clearly qualified my statements by

saying "that's for throughput".

Suggesting something to come next, that didn't come.
Performance is not STR, STR is only a small part of performance.

I never mentioned access time in that passage.

Shame on you.

You were the one that mentioned that.


Sorry, but reducing latency still makes sweet FA difference to overall
system speed. A system is made up of many components. The hard drive
subsystem is only one.

And it holds up almost everything.

It isn't used all the time - the CPU and main memory are much more important.

Which is useless when it's idling.

Improving one aspect (latency) of one subsystem (the hard drive subsystem)
just won't make any difference to overall system performance.

I just said it did.

I see a page listing results for a number of drives using a general-purpose
hard drive benchmarking tool.

Yes, that is so so bad, isn't it. It verges on the criminal, don't you think?
Stop that posturing, Church!

I must have missed the bit where they took two
drives (one IDE, one SCSI) that were as similar as possible (same
manufacturer, size, number of platters etc) and attempted to take as
many other factors out of the equation so they could test how much of a
difference improved access time makes to the hard drive sub-system.

Uhuh. And where can I order those 2 drives?

That is plain stupid, Church! The fact that they are NOT the same size,
and number of platters makes that SCSI has the better access times in
the first place. Smaller but faster rotating platters, lesser track- and
areal density is what is making SCSI equally fast to IDE but with vastly
superior access times.

Of course. But a 10% improvement in the hard drive subsystem does not equate
to a 10% overall system improvement.

Bingo. Indeed, it does not. And no Church, I don't do back-flips.

Of course. And if the hard drive was being accessed 100% of the time
(and if you ignore drive buffers), this would have the direct overall system
performance you wish existed. But drives aren't used 100% of the time. They
are used fairly rarely really, when compared to the CPU and main memory.

The main time you hit the hard drive is when launching an application.
Sure, impoved access time can help a little here, maybe even quite a bit if the
application is small.

Huh? You won't notice anything when something executes in less than 1 or 2 seconds.
It's on the longer loads that you are going to notice a 1 or 2 second difference.

But if you are loading up a decent sized app (Word, IE, Outlook, Photoshop,
Dreamweaver etc) the difference access time makes quickly approaches zero.

Large apps using lots of libraries, consisting of many many IOs that are executed
in parallel. It's obviously here that access time will make a difference.

Pointing out errors in grammar, spelling etc in other's posts is a sure sign
that you have an otherwise weak argument.

Hey, if that makes you happy after all your non-arguments and hearsay,
go for it.

You can add the word 'secondly' to the start of the quoted
sentence if it makes you happy. So firstly it makes no no-
ticable difference, and secondly it is a lot more expensive.

Nope, you did nothing of the kind.

Of course I did.

You have just spent your last post arguiing the benefits of access time.
Lets look at one of the components that influences access time - rotational
latency. Do you really think rotational latency has an affect only on access
time, and no affect whatsoever on sustained transfer rate? Of course not.

Somewhere in that gibber will be a point that you are making.
Only God knows what it is.

Since you are being so pedantic, Church is my last name hence that would be
Mr Church.

I never call a troll 'mister', sorry.

If you were to use my first name, simply saying Gareth would be fine.

And by the way, having an opinion that differs to yours doesn't make
me a troll.

It does when you turn that into a negative comment s.a.
"You just like to argue, don't you?"
Or was that a compliment, Church? No? Didn't think so.

In fact, the majority of the world differs with your opinion

Ah, and therefor I must be wrong and you must be right.
What was it about that VHS vs Beta or MAC vs PC debate again, Church?
"It's the sort of thing people say when they have a strong opinion, but
can't come up with any actual reason why they feel the way they do"?

(that SCSI should be used in the desktop environment if there will be a lot
of multitasking, because the vast majority of the world in that situation
use IDE).


It takes two to argue.
I certainly am arguiing, because I disagree with the
advice you are giving the OP.

I never give advice, Church. I present arguments on which to make decisions.

I think it would be a waste of money for him to go with SCSI.

I don't think he would notice any difference in the
performance of his system at all, and I think it is also a bad idea from the
point of view of future-proofing. As SCSI becomes less and less common, the
hardware will become more expensive. If he already has SCSI in place in his
system, each time he upgrades he will need to decide whether to pay the
extra to get another SCSI drive, or if it is worth switching over to the far
more ubiquitous and cheaper IDE.

Also, it may be convinient for you to suggest all the arguiing is from me,

I didn't, Church.

and that you are completely innocent, but I'm afraid it's also hypocritical.

Suggesting that I did, yes, that certainly is, Church.

I do not understand why you are advocating SCSI drives for use in a
desktop machine. I am asking if it is only for the better access time,
or if you actually have a good reason to hold your point of view.

Is the 'No?' a question, or are you answering mine

Oh, was your's a question then?

(just with an erroneous question mark)?

Which one, your's or mine?

Sorry, but that is no misconception.

Yes it is, as I have proven with several drives from 1997.

I don't have data on old drives, so will use modern ones:

That proves 'FA' about "But SCSI has traditionally been 'a lot' faster".

Seagate Cheetah 15K.3 - STR: 49-75 megs/sec
Seagate Barracuda 7200.7 - STR: 32-58 megs/sec

And your point is? Except debunking your own statement
about IDE having caught-up so much, compared to SCSI?

Seagate Cheetah 15K.3 - access time: 4.7ms
Seagate Barracuda 7200.7 - access time: ~12 ms

A ~150% difference.
What was that about that "slightly better access time" again, Church?

In your opinion 25% is "a lot" but 150% is slightly better.
You are making a lot of sense, Church, as usual.

Nope, problem is you have no point, and you have not been able to disprove
anything I've said. You've got your opinion, and you're going to stick to
it - no matter what the reality is.

Ah, and you're not. Right.

Like it or not this thread is about SCSI vs IDE, and which one is better in
the OPs situation. Talking about how CPUs etc have improved over time is not
relevant.

Even talking about how much drives have changed over time is irrelevant.

I'm glad you agree, ignoring your constant posturing to the contrary, that that
certainly was a stupid statement of your's.

What matters is which is best for this person in this situation.
If you can't see that is a consistent point of view, then that is your problem.

It's not my problem, Church.

Your blindness to reality is staggering. What exactly are your reasons for
thinking that SCSI is better for the OP?

What, you suddenly can't find my quotes anymore? Talking about blindness.

It has been my position all along that SCSI is not appropriate for the OP.

That was not the question. The question was if there formerly -'were'- reasons
to use SCSI in a desktop machine.

You have been the one advocating SCSI. Does this mean that you have now done
a back-flip and realised that SCSI isn't appropriate.

Is that a question, Church? In that case : No, I don't do back-flips.

BTW, the line "there never were" was yours, not mine. So you are actually
asking "so you agree?" to yourself.

No Church, it doesn't work that way. You didn't 'argue' with what I said there
so I asked whether you agreed (or not). It was you who 'suggested' that SCSI
might have been appropriate for a desktop machine, once, but not anymore.

What two? CAD software and hardware? Yes, professional CAD software is
usually run on high-end workstations.

Thank you. You were just arguing for argument sake then.

And I said that there has been a shift from SCSI to IDE in these workstations.

No Church, you didn't.

Did you have a point?

Is that a question, Church?

Well, that wasn't obvious.

Yes, it *was* obvious since I mentioned it in the next comment for explanation.
It's also obvious, as that has always been IDE's best known bottleneck.

The interface has had many improvements. The connectors are different
(much smaller), the power connector has changed (and now includes 3.3v),
it has a faster theoretical limit, the limit to cable length has been increased,

and yes SATA uses just one channel per device.

Gee, didn't I mention that? You must have missed it then, eh?

If you think it is obvious what you were referring to, then clearly
you have a complete inability to see things from other people's point of
view, because it was anything but obvious.

Blablabla, whine, whine, whine, whatever. No wonder this post has grown so big.
Stop the posturing, Church.

If you have a point, no I don't.

Yeah, that's what I thought.

Indeed, not that it's a problem.

Yes Church, that is a problem with any shared bus: You have to
share it. Like when you share a cookie you each get half a cookie?
It's actually a very simple concept.

Like I said, you obviously don't have a clue.

Haha.

Clueless, indeed.
When you copy a 60MB/s drive to another one on the same channel
you need (2*60) +10% = 133 MB/s bandwidth to copy at full speed.
An ATA66 channel will have them transfer at only half their speed.
An ATA100 channel will have them transfer at approx. 45MB/s each.

In the real world you rarely are trying to read/write to multiple drives at
the same time.

Of course you do. And you certainly do on RAID.
Oh, what a coincidence, didn't you advise RAID?

Having multiple applications open at once does not equal
having multiple applications accessing drives at once. About the only time
when you will access two devices at once is when you are doing something
like copying a CD to your hard drive. This operation is obviously limitied
in speed to the CD, so it doesn't matter that the hard drive is pulled back
to the CD drives speed.

Another example may be if you are encoding video in the background while
doing something else in the foreground. But video encoding takes a lot of
CPU, so you are much more likely to notice the speed dip because of that
than the hard drive speed (if you even happen to use the hard drive in the
foreground app, which you probably aren't).

Your ability to reduce problems to mere nothingness is truly jaw-dropping,
Church.

Is there an imposed limit on SATA?
Yes.

I would imagine it would be how many controllers you could
fit on a PCI card, and how many spare PCI slots you have.

It's not as bad as that.
More like how many drives can be attached to a port multiplexer.
but then it stops. You can't 'multiplex' a port multiplexer.

That is going to allow enough drives for all but the absolutely most
essential server, which wouldn't have considered IDE anyway.

A hosting server sure would consider IDE for storage and need lots
of them.

You just said they could be the same drive.

Sigh! Yes Church. Do I have to spell it out for you, word for word, letter
for letter or will you be able to grasp it on your own, if you try harder?

 

[Folkert Rienstra]

Can you provide specifics?

I'm currently using two 36 GB Ultra160 drives from Seagate.

Which ones?

One is about a year old, the other, probably three years old. I believe
their idle noise level was rated around 3.4 bels, and I don't know of any.
standard SCSI drives which are much quieter than that. I find the
noise very bothersome.

According to c't the Atlas 15k should be quiet on idle (1 Sone).
Barracuda 32ES2 is even quieter at 0.3 Sone and 0.8 Sone seeking,
but is relatively slow as it is 7200rpm.

 

[Folkert Rienstra]

On a tough job, in difficult terrain (In a server, IO/s) the SCSI will go on
and on, and not wear itself down. The IDE will break down in performance.
They can have the same maximum speed on the road but offroad the V8 will
move ahead of the 4Cyl.

Only a moronic top poster could come up with such a stupid, wrong, analogy.

Good analogy, lousy explanation.

 

[Jonathan Sachs]

According to c't the Atlas 15k should be quiet on idle (1 Sone).
Barracuda 32ES2 is even quieter at 0.3 Sone and 0.8 Sone seeking,
but is relatively slow as it is 7200rpm.

Sorry but I don't remember, and since it isn't likely to be relevant
I'm not going to take the time to unscrew the drives and find out. Now
that I think about it, though, I'm pretty sure that the older one is
an Atlas IV, not a Seagate.

I've pretty definitely decided that my next set of drives will be
serial ATA. I'm now puzzling over whether I can find a
high-performance serial ATA drive that is significantly quieter than
SCSI.

My mail address is jsachs177 at earthlink dot net.

 

[Folkert Rienstra]

Sorry but I don't remember, and since it isn't likely to be relevant
I'm not going to take the time to unscrew the drives and find out.

The OS should be able to tell you. If you can name the drives then I
could lookup the noiselevels for you, for comparison.

Now that I think about it, though, I'm pretty sure that the older one is
an Atlas IV, not a Seagate.

Well, the ATLAS IV has an idle noise of 2 Sone (the 15k at 1 sone should
therefor be half as loud) and a seek noise of 6 Sone. Btw, the seek noise
of the 15k is 3.7 Sone.

I've pretty definitely decided that my next set of drives will be
serial ATA. I'm now puzzling over whether I can find a high per-
formance serial ATA drive that is significantly quieter than SCSI.

With a choice of 1 that may prove a bit difficult.