10,000 RPM? - think twice before you throw money at a Raptor

S

stockDrover

Is it time to rethink?

According to reportlabs.com,

PassMark Diskmark for a WD1500AHFD: 445.1

I put 3 WD1600YS in RAID 5 (same total cost:$180.00).

PassMark DiskMark for WD1600YS in RAID 5: 674.4

These drives are 7200 RPM with 16mb Cache, 5 year warranty, and just
60/drive.

Everything I read here led me to believe that RAID 5 performance would
be miserable.

In fact, its 52% faster than a 10000 rpm highbux but sadly SATAI
Raptor.

Here is the breakdown:
Raptor RAID5 WD1600YS (x3)
Sequential Read: 84.5 100.6
Sequential Write: 78.1 81.0
Random seek+RW: 5.9 5.3

The RAID is via Intel Matrix Storage Manager (hardware) on Asus P5E
MB. The system supports SATA II as well as NCQ, as do the disk drives.
IMSM has enabled write caching on the array.

The big suprprise to me is that sequential writes are actually
faster. This is comparable to normal personal disk tasking; output
form a a compiler/linker, saving your document, writing the hiber-file
(ahem!) before going to sleep

With parity burden and slower rotation, its only natural that Random
Seek+RW is slower, but I'd say that a 10% deficit is a good trade off
for twice the disk space (~306 gb) and the super-duper-totally-nifty-
any-one-disk-can-fail-without-loss fault tolerance.

I wonder how much of this is due to the bigger pipe (3 g/s)? How much
to NCQ + 16mb caches?

While this might not be the ideal setup for a database server, it's a
great choice for a high performance personal/development system.
Particularly if you think (as I do) that BACKUP of modern storage
volumes is a ridiculous exercise.

regards,

stockdrover
 
K

kony

Is it time to rethink?

According to reportlabs.com,

PassMark Diskmark for a WD1500AHFD: 445.1

I put 3 WD1600YS in RAID 5 (same total cost:$180.00).

PassMark DiskMark for WD1600YS in RAID 5: 674.4

These drives are 7200 RPM with 16mb Cache, 5 year warranty, and just
60/drive.

Everything I read here led me to believe that RAID 5 performance would
be miserable.
Click to expand...

Not miserable, just not the "performance" choice, that it
has lower performance than other options.

In fact, its 52% faster than a 10000 rpm highbux but sadly SATAI
Raptor.

Here is the breakdown:
Raptor RAID5 WD1600YS (x3)
Sequential Read: 84.5 100.6
Sequential Write: 78.1 81.0
Random seek+RW: 5.9 5.3
Click to expand...

I don't understand your math, none of these numbers show a
52% benefit. What these numbers show is that it requires 3
drives just to beat one Raptor, and these are synthetic not
real-world usage tests where the RAID overhead might matter.
There are many different uses for a drive, different access
patterns may benefit more or less from a RAID5 array.

Consider you would have far more performance from a RAID0 of
two Raptors, then a 3rd drive could backup that RAID0 array.
The RAID is via Intel Matrix Storage Manager (hardware) on Asus P5E
MB. The system supports SATA II as well as NCQ, as do the disk drives.
IMSM has enabled write caching on the array.
Click to expand...

I suspect you will have to disable write caching to get
meaningful benchmark numbers.

The big suprprise to me is that sequential writes are actually
faster. This is comparable to normal personal disk tasking; output
form a a compiler/linker, saving your document, writing the hiber-file
(ahem!) before going to sleep
Click to expand...

The difference in write speed was so slight you would never
notice in typical uses, and again this is only a synthetic
test which may or may not be equivalent to tasks you list as
merely something that writes to drives.


With parity burden and slower rotation, its only natural that Random
Seek+RW is slower, but I'd say that a 10% deficit is a good trade off
for twice the disk space (~306 gb) and the super-duper-totally-nifty-
any-one-disk-can-fail-without-loss fault tolerance.
Click to expand...

It depends a lot on whether you need this much space, and if
you need space you could buy a 500GB drive today for about
$100 USD.


I wonder how much of this is due to the bigger pipe (3 g/s)? How much
to NCQ + 16mb caches?
Click to expand...


No significant difference from it being SATA300 instead of
SATA150, and NCQ tends to help most in server/concurrent IO
scenarios. The cache will help some but not very much going
from 8MB to 16MB as it would comparing 2MB or 4MB to 8MB.


While this might not be the ideal setup for a database server, it's a
great choice for a high performance personal/development system.
Particularly if you think (as I do) that BACKUP of modern storage
volumes is a ridiculous exercise.
Click to expand...

It is not a "high peformance" choice. It is actually going
to be slower in many uses than if you had kept the drives as
separate volumes, for example when working with very large
files if you were reading from one drive and writing to a
separate volume, or when reading a lot of files if you had
the operating system on one drive and application on
another, data files on the least used of these two separate
volumes.

Whether you get good performance from this configuration
depends a lot on exactly how you're using them. It is not a
substitute for making backups. Offline backups guard
against motherboard failure (with this integrated Intel RAID
you have to have another similar motherboard to get the data
off if the board fails), guard against user error, guard
against data corruption, malware/viri, damaging power
surges, etc. Having redundancy in a RAID array is most
useful for maintaining uptime, that the system functionality
is not prevented until a drive is replaced and data copied
back.

I don't mean to suggest a RAID5 is not the right choice for
you, it may be the best compromise for your needs and you
are getting reasonable performance from it, but it is a
fairly random test to compare a synthetic benchmark of one
Raptor versus a 3 drive RAID5, plus your present array is
only "~306GB" which isn't all that much today for having 3
drives dedicated to it.
 
B

Brett Kline

stockDrover said:
Everything I read here led me to believe that RAID 5 performance would
be miserable.

In fact, its 52% faster than a 10000 rpm highbux but sadly SATAI
Raptor.

Here is the breakdown:
Raptor RAID5 WD1600YS (x3)
Sequential Read: 84.5 100.6
Sequential Write: 78.1 81.0
Random seek+RW: 5.9 5.3

The RAID is via Intel Matrix Storage Manager (hardware) on Asus P5E
MB. The system supports SATA II as well as NCQ, as do the disk drives.
IMSM has enabled write caching on the array.
Click to expand...


It's software RAID which relies on the CPU.



http://www.newegg.com/Product/Product.aspx?Item=N82E16816131002

Here is a mid-range HBA.


The big suprprise to me is that sequential writes are actually
faster. This is comparable to normal personal disk tasking; output
form a a compiler/linker, saving your document, writing the hiber-file
(ahem!) before going to sleep
Click to expand...

Several aspects of RAID strike me as being counterintuitive.
With parity burden and slower rotation, its only natural that Random
Seek+RW is slower, but I'd say that a 10% deficit is a good trade off
for twice the disk space (~306 gb) and the super-duper-totally-nifty-
any-one-disk-can-fail-without-loss fault tolerance.
Click to expand...

For mission critical applications RAID6 is a better choice.


http://tweakers.net/reviews/557/1/comparison-of-nine-serial-ata-raid-5-adapters-pagina-1.html
 
P

Paul

stockDrover said:
Is it time to rethink?

According to reportlabs.com,

PassMark Diskmark for a WD1500AHFD: 445.1

I put 3 WD1600YS in RAID 5 (same total cost:$180.00).

PassMark DiskMark for WD1600YS in RAID 5: 674.4

These drives are 7200 RPM with 16mb Cache, 5 year warranty, and just
60/drive.

Everything I read here led me to believe that RAID 5 performance would
be miserable.

In fact, its 52% faster than a 10000 rpm highbux but sadly SATAI
Raptor.

Here is the breakdown:
Raptor RAID5 WD1600YS (x3)
Sequential Read: 84.5 100.6
Sequential Write: 78.1 81.0
Random seek+RW: 5.9 5.3

The RAID is via Intel Matrix Storage Manager (hardware) on Asus P5E
MB. The system supports SATA II as well as NCQ, as do the disk drives.
IMSM has enabled write caching on the array.

The big suprprise to me is that sequential writes are actually
faster. This is comparable to normal personal disk tasking; output
form a a compiler/linker, saving your document, writing the hiber-file
(ahem!) before going to sleep

With parity burden and slower rotation, its only natural that Random
Seek+RW is slower, but I'd say that a 10% deficit is a good trade off
for twice the disk space (~306 gb) and the super-duper-totally-nifty-
any-one-disk-can-fail-without-loss fault tolerance.

I wonder how much of this is due to the bigger pipe (3 g/s)? How much
to NCQ + 16mb caches?

While this might not be the ideal setup for a database server, it's a
great choice for a high performance personal/development system.
Particularly if you think (as I do) that BACKUP of modern storage
volumes is a ridiculous exercise.

regards,

stockdrover
Click to expand...

There is something wrong with these results. For purely random access (i.e.
disk subsystem is asked for information which has not been accessed
recently, and is not in cache), the disks should be showing the
physical limitations of their seek time. The 10000 RPM disk should
have a lower seek time than the 7200RPM disk. (Average rotational
latency is 1/2 a rotation, and the seek time should reflect that
physical limitation.) It means the benchmark is hitting in the cache,
rather than missing the cache and going to disk. The benchmark program
sucks.

The reason you buy a 10000 or 15000 RPM disk, is for reduced seek time
and the potential for more I/O operations per second.

If everything you do, lands in some cache, then that would be great.
For example, if you are a developer, and do rebuilds of the same source
files over and over again, get a hardware controller card with a
cache DIMM slot on it. Plug a 1GB DIMM into the slot. As long as
the amount of source being accessed is less than 1GB, you'll never
have to wait for the physical disk, as all requests can be answered
from cache. Once the cache has been filled, by the first attempted
build, then the files will be in the cache.

Paul
 
B

Brett Kline

kony said:
OK, but when the system is waiting for data I/O from the
HDD(s), what else did the CPU have to process during this
interval? IMO, there is not much difference today whether
soft or hard RAID, only the matter of caching unless it is a
use more common with a server environment.
Click to expand...


The Promise and HighPoint controllers I've used had unacceptably high CPU
utilization, incompatibility issues with Maxtor DM+ 9 hard drives and
generally sluggish RAID5 performance. It's a waste to spend $150-$225 for
the same performance level as a motherboard Nvidia, Intel, or JMicron
solution.

Some of the better HBAs use the Intel 800MHz 81341 at 800MHz, others the
Intel IOP331/IOP333. Depending on the level of RAID, number of disks, brand
of disk, amount of cache, OS, and how and where parity calculations are
implemented, I'm inclined to concede in specific cases.

The Promise SuperTrak EX8350 uses the Intel IOP333, which makes it very
different from the FastTRAK S150 SX4 and the TX series. The HighPoint
RocketRAID 3520 appears to use the Intel IOP 80341, which is top notch.
 
Top