Raptor or SCSI - Which is going to perform the best?

[Folkert Rienstra]

What matters for a good gamer PC is, in rough order of importance:
1. Memory capacity: at least 1GB, 2GB better, 4GB is best
2. Memory latency: insist on dual-channel, the faster the better
3. CPU chip speed: faster is better, 64b does not matter yet
4. Video card: see http://graphics.tomshardware.com/graphic/20031229
5. HD access time

To focus on HD performance, after taking care of items 1-4 above, note
that I listed access time as the key attribute -- not bandwidth. HD
vendors tout bandwidth, usually advertising the irrelevant peak bandwidth
instead of STR, but access time matters more

for all but servers.

You do that on purpose, don't you Bob.
Adding unneccesary little tidbits and then getting them wrong.

The access times for two performance leaders are: WDC Raptor 74GB SATA at
7.5 mS (4.5+3.0),

and Seagate Cheetah 15K 73GB SCSI at 5.6 mS (3.6+2.0).

Must be an older Cheetah.

SCSI is still the clear winner if you ignore cost; but, SATA is built-in
on most good MBs these days,

while a good SCSI HBA is pretty expensive
(the Adaptec 29320ALP-R, for example, lists for ~$395).

But you don't need that one. An Ultra2 will do fine for single drive access.

Note that WinXP did not have good support for SCSI. I don't know if SP2
fixed the XP problems, and I'd not pay for SCSI without making very
sure on that point.

One highly proclaimed storage feature is command queueing. SCSI has had
TCQ for years, SATA has NCQ in some hardware but limited driver support,
and PATA just doesn't get it.

CQ is very important for database and some storage Oserver workloads,

And OSes that do parallel IO.

but it has near-zero value for a PC in a single-user environment

(except, maybe, for some CAD and software development workloads).

And OSes that do parallel IO.

 

[Ron Reaugh]

In message <[email protected]>


Is the difference significant?

It's more than the cylinder size difference but the 36GB isn't slow but it
may be slower than the Hitachi 7K400.

 

[Marc Brown]

I doubt that the "chug"
you're seeing has anything to do with the CPU workload in accessing the
drive--copying files typically shows one percent utilization on my machine.

The problem doesn't seem to be that the CPU gets a big bite taken
out of it, because I can personally confirm that this is not the
case. Rather, it seems to be a Windows-originated inadequacy:
Whenever the drive is accessed, the potential seems high that
whatever process handles multitasking will choke. I experience
it all the time, every day. Say, I'm listening to an mp3. Hardly
CPU intensive, or demanding on the drive. But then I go type
something and it's like the PC has to take a split second to load
text graphics. No big deal, except that during that split second,
mp3 playback pauses, resulting in a minor delay / pop in the audio.
A better example: FPS games used to (and maybe still do) allow one
to "precache" all data associated with a given level before
beginning the level. Why? Because, regardless of whether or not
one suspected that drive access was the culprit, the simple _fact_
was that the games would pause whenever something that hadn't been
already loaded into ram was suddenly required. Absolutely
intolerable in a FPS game, hence the fix. I think drive access
has everything to do with the "chug". The only thing I'm not
clear on is whether a proper SCSI controller card will work to
reduce the phenomenon by preventing the CPU from having to force
everything to pause while it taps the drive.

Personally I'd max out the RAM on the machine before I tried a faster drive.

Unfortunately, it is known, at least to those who visit forums
relating to performance and overclocking, that adding more than
1GB of ram actually tends to have a negative impact on performance.
I do of course refer to day-to-day and/or gaming performance, and
not, say, Photoshop performance.

 

[Ron Reaugh]

"Marc Brown" (e-mail address removed)> wrote in message The question isn't as pointless and rhetorical as it may seem. A
friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".

Talking about a Western Digital Raptor Serial ATA drive, right ?

In the past, one of SCSI advantages is that it took the load off the CPU for
SCSI device (hard drive, scanner, tape backup, etc) access.

That has NEVER been true since EIDE/ATA HDs used DMA mode and that was
OSR2 and NT4 SP4.

A SCSI controller is better at managing multiable SCSI (5 or 10 or
15) devices at the same time

Exactly, that's where that onboard smarts contributes..multiple devices.
SCSI's onboard smarts does not help it be faster than 1 or 2 ATA HDs.

IDE/ATA controllers can handle one data request at a time
SCSI also has better ways of handling multiable data requests, which are
just now being added to the S-ATA (Data Queing ?).

That contributes to performance on small record I/O database servers and NOT
single user workstations.

In fact all those extra features of SCSI inhibits
optimal performance on a single user workstation.

Clueless. There is no such fact.

Wacko. It is that extra overhead of SCSI that causes late model 15K RPM
SCSI HDs to fall into a tie with 10K RPM Raptors for best performance on a
single user workstation.

 

[Ron Reaugh]

Back with your SCSI/IDE delusions, Ronnie?

SCSI drives have faster processors and lower command overhead.

WRONG!

 

[CJT]

That's potentially true,

Nope.

[snip]

Yep.

 

[Ron Reaugh]

Marc Brown wrote:

The question isn't as pointless and rhetorical as it may seem. A
friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".


That's potentially true,

Nope.

[snip]

Yep.

Wrong, SCSI HBAs do NOT remove any kind of CPU load that ATA controllers
suffer from. There's no SCSI advantage there.

 

[Eric Gisin]

WRONG!

RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!!
RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!!

 

[J. Clarke]

The problem doesn't seem to be that the CPU gets a big bite taken
out of it, because I can personally confirm that this is not the
case. Rather, it seems to be a Windows-originated inadequacy:
Whenever the drive is accessed, the potential seems high that
whatever process handles multitasking will choke. I experience
it all the time, every day. Say, I'm listening to an mp3. Hardly
CPU intensive, or demanding on the drive. But then I go type
something and it's like the PC has to take a split second to load
text graphics. No big deal, except that during that split second,
mp3 playback pauses, resulting in a minor delay / pop in the audio.

Unless your player has adequate buffering, this would be the expected
result. It has nothing to do "whatever process handles multitasking"
"choking". The MP3 is being read from the drive. The text is being read
from the drive. Only one thing can be read from the drive at a time--to
read one thing it must stop reading something else.

A better example: FPS games used to (and maybe still do) allow one
to "precache" all data associated with a given level before
beginning the level. Why? Because, regardless of whether or not
one suspected that drive access was the culprit, the simple _fact_
was that the games would pause whenever something that hadn't been
already loaded into ram was suddenly required.

Since the only way something gets loaded into RAM is to read it off he
drive, drive access is necessarily the culprit.

Absolutely
intolerable in a FPS game, hence the fix. I think drive access
has everything to do with the "chug".

But not in the way that you seem to think.

The only thing I'm not
clear on is whether a proper SCSI controller card will work to
reduce the phenomenon by preventing the CPU from having to force
everything to pause while it taps the drive.

Since the pause is caused by the game waiting for data to be read from the
drive, and since that is a limitation of the physical structure of the
drive, a SCSI host adapter of any kind will not solve your problem.

Unfortunately, it is known, at least to those who visit forums
relating to performance and overclocking, that adding more than
1GB of ram actually tends to have a negative impact on performance.
I do of course refer to day-to-day and/or gaming performance, and
not, say, Photoshop performance.

In that case, your problem is insoluble.

 

[Marc Brown]

You've either skipped a few steps in optimizing for gaming,
or at least failed to mention these steps, in addtion to
failing to mention the specific system. "Chug" is a
meaningless word, precise description of the environment is
necessary. Does friend's system play same game fine,
without "chug"? If so, is friend's system IDENTICAL
otherwise?

Chug has happened on every system I have ever experienced, all the
way up to the FX-53 2GB box sitting behind me. Although I admit
to only limited exposure to Linux. Chug simply happens. In an
earlier post, I provided the example of mp3 playback being
interrupted, reliably, reproducably, and semi-predictably. The
interruption is on the order of 1/30th of a second, but it
still counts as "chug". Basically, anything that causes an
anomaly like that (audio pausing for a split second, framerate
freezing for a split second, etc.), effectively underscoring a
poor or false multitasking system, counts in my book as "chug".
I have been able to correlate instances of chug with drive access
in nearly every identified case. Regardless of why drive access
seems to be the culprit, it is tempting to imagine that any
method by which the impact of drive access on the CPU can be
eliminated would be advantageous.

You were told wrong. Find another noun instead of "chug".

Not here to offend anyone. What would you call it? I've given
a description above and it's not exactly an ambiguous phenomenon.

Since
you make no mention of the specific environment, we can only
speculate that the HDD choice isn't a solution.

There wasn't a particular need to mention specs or applications
because the idea was to determine whether or not a SCSI controller
card would reduce whatever load was hypothetically responsible for
engendering the split-second performance blackouts of which I
speak. If it helps, I certainly have tried plenty of combinations
of hardware to see if the problem could ever be eliminated, with
the obvious exception of utilizing a SCSI solution.

Now at this point i should mention, I'm not just aiming to
tear apart your post, but to do so constructively. Plenty
of gamers use relatively older, slower drives and have no
"chug".

Back when I used to play FPS games, there was an option
introduced to Quake2 called "precache", which would, I suppose,
load all potentially relevant graphics into ram before playing a
match, as opposed to during gameplay. The purpose was to
circumvent the possibly catastrophic framerate stutterings which
tended to result from drive access. In this example, the
stuttering surely resulted from the game's inability to proceed
with gameplay prior to retrieving whatever data it was after,
but as I mentioned above, the problem can and does occur under
WinXP's supposedly multitasking environment.

Anyway, if SCSI isn't going to reduce the CPU load, then it's
moot.

 

[Ron Reaugh]

Chug has happened on every system I have ever experienced, all the
way up to the FX-53 2GB box sitting behind me. Although I admit
to only limited exposure to Linux. Chug simply happens. In an
earlier post, I provided the example of mp3 playback being
interrupted, reliably, reproducably, and semi-predictably. The
interruption is on the order of 1/30th of a second, but it
still counts as "chug". Basically, anything that causes an
anomaly like that (audio pausing for a split second, framerate
freezing for a split second, etc.), effectively underscoring a
poor or false multitasking system, counts in my book as "chug".
I have been able to correlate instances of chug with drive access
in nearly every identified case. Regardless of why drive access
seems to be the culprit, it is tempting to imagine that any
method by which the impact of drive access on the CPU can be
eliminated would be advantageous.

Depending on a number of things that 'chug' might not actually be due to CPU
access but bus bandwidth saturation. The DMA bursts to/from the HD could be
starving the CPU. Newer mobos using the more advanced chipsets and dual
channel RAM may not tend 'chug' so much.

I like to hear if you experience 'chugs' on a P4/800 HT CPU using dual
channel memory on an Intel 875 chipset mobo in XP.

There wasn't a particular need to mention specs or applications
because the idea was to determine whether or not a SCSI controller
card would reduce whatever load was hypothetically responsible for
engendering the split-second performance blackouts of which I
speak.

There is NO theoretical reason to suspect that SCSI would behave any
different.

If it helps, I certainly have tried plenty of combinations
of hardware to see if the problem could ever be eliminated, with
the obvious exception of utilizing a SCSI solution.

SCSI offers nothing special in this arena.

 

[J. Clarke]

Chug has happened on every system I have ever experienced, all the
way up to the FX-53 2GB box sitting behind me. Although I admit
to only limited exposure to Linux. Chug simply happens. In an
earlier post, I provided the example of mp3 playback being
interrupted, reliably, reproducably, and semi-predictably. The
interruption is on the order of 1/30th of a second, but it
still counts as "chug". Basically, anything that causes an
anomaly like that (audio pausing for a split second, framerate
freezing for a split second, etc.), effectively underscoring a
poor or false multitasking system, counts in my book as "chug".

Pausing to load data is not evidence of a poor or false multitasking system,
it is evidence of a single disk drive trying to serve two processes.

I have been able to correlate instances of chug with drive access
in nearly every identified case. Regardless of why drive access
seems to be the culprit, it is tempting to imagine that any
method by which the impact of drive access on the CPU can be
eliminated would be advantageous.

The only way you can do that is to develop a storage device that can deliver
data faster than the CPU can accept it.

Not here to offend anyone. What would you call it? I've given
a description above and it's not exactly an ambiguous phenomenon.

Try a "pause". "Chug" is what a steam locomotive does going up a grade.

There wasn't a particular need to mention specs or applications
because the idea was to determine whether or not a SCSI controller
card would reduce whatever load was hypothetically responsible for
engendering the split-second performance blackouts of which I
speak.

Since those "blackouts" are not caused by "load" but by waiting for a disk
to deliver data the host adapter cannot help.

If it helps, I certainly have tried plenty of combinations
of hardware to see if the problem could ever be eliminated, with
the obvious exception of utilizing a SCSI solution.


Back when I used to play FPS games, there was an option
introduced to Quake2 called "precache", which would, I suppose,
load all potentially relevant graphics into ram before playing a
match, as opposed to during gameplay. The purpose was to
circumvent the possibly catastrophic framerate stutterings which
tended to result from drive access.

Yes, since everything is already loaded it is not necessary for the game to
wait for data to be read from the drive.

In this example, the
stuttering surely resulted from the game's inability to proceed
with gameplay prior to retrieving whatever data it was after,
but as I mentioned above, the problem can and does occur under
WinXP's supposedly multitasking environment.

And it happens because multitasking does not make the drive deliver data any
faster.

Anyway, if SCSI isn't going to reduce the CPU load, then it's
moot.

If you investigate you will find that the CPU load is _lower_ when these
"chugs" occur than at other times because the CPU is idling waiting for the
disk to deliver data that it needs in order to continue processing.

 

[CJT]

"CJT" <[email protected]> wrote in message

Marc Brown wrote:


The question isn't as pointless and rhetorical as it may seem. A
friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".


That's potentially true,


Nope.

[snip]

Yep.

Wrong, SCSI HBAs do NOT remove any kind of CPU load that ATA controllers
suffer from. There's no SCSI advantage there.

So SATA does access reordering?

 

[Ron Reaugh]

Folkert Rienstra wrote:


Marc Brown wrote:


The question isn't as pointless and rhetorical as it may seem. A
friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".


That's potentially true,


Nope.

[snip]

Yep.

Wrong, SCSI HBAs do NOT remove any kind of CPU load that ATA controllers
suffer from. There's no SCSI advantage there.

So SATA does access reordering?

The issue was "SCSI controller card takes the load off the CPU during drive
access".
The above quote is false as it relates to any advantage over SATA. "access
reordering" is done onboard a SCSI HD and not the controller and has nothing
to do with the issue at hand.

 

[CJT]

Folkert Rienstra wrote:





Marc Brown wrote:



The question isn't as pointless and rhetorical as it may seem. A
friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".


That's potentially true,


Nope.

[snip]

Yep.


Wrong, SCSI HBAs do NOT remove any kind of CPU load that ATA

controllers

suffer from. There's no SCSI advantage there.

So SATA does access reordering?

The issue was "SCSI controller card takes the load off the CPU during drive
access".
The above quote is false as it relates to any advantage over SATA. "access
reordering" is done onboard a SCSI HD and not the controller and has nothing
to do with the issue at hand.

Whatever. I doubt the OP cares whether it's done on the controller
card or the disk drive electronics, but perhaps (s)he does.

 

[kony]

Whatever. I doubt the OP cares whether it's done on the controller
card or the disk drive electronics, but perhaps (s)he does.

May not make any difference if the sole problem was a game
waiting to load a file, not multiple accesses.

 

[CJT]

May not make any difference if the sole problem was a game
waiting to load a file, not multiple accesses.

Yes, as with all such queries in the abstract, the devil is in the
details. The only way to proceed with certainty is to monitor and
analyze the specific system in question and identify and address its
bottlenecks. If disk access isn't an issue, then throwing money at
the disk subsystem will be wasted.

 

[Folkert Rienstra]

"Marc Brown" (e-mail address removed)> wrote in message The question isn't as pointless and rhetorical as it may seem.
A friend of mine can't get over the cool factor of his shiny new
Raptor. I, on the other hand, have been investigating SCSI as my
storage platform of choice. In both cases, gaming is the target
application. In researching SCSI options, my primary aim is to
minimize in-game "chug", which is to say the brief (or sometimes
protracted) performance pauses which seem to coincide with drive
access. I have been told that the SCSI controller card takes the
load off the CPU during drive access, with the result being little
to no discernable "chug".

Talking about a Western Digital Raptor Serial ATA drive, right ?

In the past, one of SCSI advantages is that it took the load off the
CPU for SCSI device (hard drive, scanner, tape backup, etc) access.

That has NEVER been true since EIDE/ATA HDs used DMA mode
and that was OSR2 and NT4 SP4.

A SCSI controller is better at managing multiable SCSI (5 or 10
or 15) devices at the same time

Exactly, that's where that onboard smarts contributes..multiple devices.
SCSI's onboard smarts does not help it be faster than 1 or 2 ATA HDs.

IDE/ATA controllers can handle one data request at a time
SCSI also has better ways of handling multiable data requests,
which are just now being added to the S-ATA (Data Queing ?).

That contributes to performance on small record I/O database servers
and NOT single user workstations.

In fact all those extra features of SCSI inhibits
optimal performance on a single user workstation.

Clueless. There is no such fact.

Wacko. It is that extra overhead of SCSI that causes late model 15K RPM
SCSI HDs to fall into a tie with 10K RPM Raptors for best performance on a
single user workstation.

No, your holy cluelessness, it is the smaller platters and not so maxed out
density in order to minimalize access time that is tying them in on STR.

The 15k rpm SCSI drives will run circles around a Raptor on non sequential
access. The Raptor will be 40% slower on random single sector access.

 

[Folkert Rienstra]

RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!!
RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!! RIGHT!!!

It's bloody irrelevant.
Command overhead only affects how much bus bandwidth headroom is needed
to not have its transfers slowed down.

Only when command overhead is starting full track accesses to cost more
than a single rev will command overhead be responsible for slowing STR down.

 

[Ron Reaugh]

May not make any difference if the sole problem was a game
waiting to load a file, not multiple accesses.

Precisely. Reordering never have anything to do with the issue of this
thread.