a comparison of hd, drivers, and raid

[bwanaaa]

I compared three drives in various configurations and am in a sharing mood. Hitachi deskstar 500 gb, Samsung spinpoint 500 gb and raptor 150 gb.
Motherboard DFI nf4 expert Venus, opteron 170 2.76 ghz, 2gb ram

i chose to upload the images as attachments rather than inline for a reason. Opening the images as new tabs allows you to click between tabs and see changes instantly.

First is a comparison of RAID.
2 raptors using the NVIDIA chipset

[bwanaaa]

4 raptors using nf4 chipset, optimal stripe

[bwanaaa]

4 raptors using 3ware PCIexpress 9650SE 4 port RAID card

[bwanaaa]

Obvious is that the write performance of the 3ware card is poor. I think maybe it's because 3ware is designed for servers so they emphasize data protection rather than performance. This particular card also does RAID6 . It goes one better than raid5 by adding another parity drive. Personally I think the whole thing is a marketing gimmick. I only tested RAID0. But on the 3ware site are a few tweaks to turn this card into a 'performer'.

FUA (Force Unit Access) can be turned off in the Windows registry. That didnt seem to do much as the pictures below show. But it can cause errors to crop up in Windows. Microsoft even has a technote about it.

However, one can also go into the card's bios and change something called the 'storesave performance profile'. The default is 'protection' but there are 2 other settings balanced and performance. Performance seems to help a bit as the graphs below show.

The text here is from the 3ware site:

When using the 7.61 code set or newer, you can tune the Windows driver to increase the write performance by modifying the Windows registry.
To disable use of the FUA (Force Unit Access) bit on SCSI writes, add the following entry to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\3ware Storage Controller]
"CacheControl"=dword:00000001
Reboot for the changes to take effect. This will increase write performance on benchmarks such as Atto BENCH32.exe.
To ignore all SRB flush commands, add the following entry to the Windows registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\3ware Storage Controller]
"CacheControl"=dword:00000010
To ignore all SCSI flush commands, add the following entry to the Windows registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\3ware Storage Controller]
"CacheControl"=dword:00000020
To ignore all flush commands and disable use of the FUA bit (fastest write performance), add the following entry to the Windows registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\3ware Storage Controller]
"CacheControl"=dword:00000031
To restore back to the default setting, add the following entry to the Windows registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\3ware Storage Controller]
"CacheControl"=dword:00000000
You can also double click on 3ware_noFUA_noflushing_cache_setting (best write performance).reg or 3ware_default_cache_setting.reg.
After double clicking on the .reg keys and entering them into the Windows registry, you must reboot in order for them to take effect.
Warning: When Windows sends a flush command to the driver, it expects that the data has been committed to disk drive. Setting the 3ware Windows driver to ignore these flush commands will cause Windows to believe that data has been committed to disk.


The Microsoft tech note is reproduced here:
Windows Performance tuning generates error:
You receive a "Delayed Write Failed" error message in Windows XP Service Pack 2
Article ID : 870894
Last Review : November 12, 2004
Revision : 3.0
SYMPTOMS
After you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows XP Tablet PC Edition 2005, you may receive the following error message during ordinary usage:
Delayed Write Failed
Windows was unable to save all the data for the file drive_letter:\file_path\file_name. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.
MORE INFORMATION
For more information about how to optimize your 3ware software, visit the following 3ware Web site:
http://www.3ware.com/KB/article.aspx?id=10697 (http://www.3ware.com/KB/article.aspx?id=10697)Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information. The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

[bwanaaa]

There is also this thing about matrix raid with the intel chipsets. I tried that with this setup but didnt seem to get much of a boost. I set up the 4 raptors in RAID 0 and partitioned the 579 gig volume into a 50 gig boot volume (bootraptor) and the remaining 450 gig (part raptor). I compared this setup to a single large volume (full raptor).

[bwanaaa]

So far, it's apparent that the NF4 chipset does better than the 3ware offerring. There is also a difference when you are just using plain old sata drives - differences resulting from not only the drive you use but which sata chipset is used. This particular motherboard has a Sil 3114 chip that drives 4 sata150 ports as well as the nvidia nf4 chipset. Getting the board to boot from the sil chipset was a little tricky. irst you have to enable the sil chipset in the bios (obviously) but then you have to set it to raid. But wait there's more. You then have to enter the Sil bios during the boot process and create a 'concatenation' of the drive you want. I think 'concatenation is Sil's term for JBOD - nothing like big words to make you feel smart. So you create a concatenation of JUST ONE DRIVE. Then you can boot from this drive. Interestingly, you can reboot and go back into the bios and reset the sil chipset to sata and the thing still works. Dont ask me what it's doing but I suppose the RAID and concatenation settings are necessary for the sil chip to meet the drives on its ports properly. So here are 2 drives the hitachi and the samsung configured to boot as sata drives from either the sil or nf4 chipset.

[bwanaaa]

sorry but it wouldnt let me put all the files up

[bwanaaa]

and the rest

[bwanaaa]

some observations again are that the samsung is a bit faster than the deskstar. The nf4 chipset is faster than the sil but the cpu utilization reported by hdtune is much greater-well you dont get 232mb/s as a burst rate for nothing! compared to the burst rate of 90 something on the sil chip that's a big difference. But that is only seen when the drive is the boot drive.

The hitachi was never configured as a boot drive. It is simply a storage drive and was tested on the sil chip and the nv chip/ The nv chip does give it a little more speed and the cpu utilization is marginally higher but still very low (<5%). However, the spinpoint drive was configured as a boot drive. And it's performance on the sil chip and the nv chip were night and day. I think I must have done something wrong because there is no way a single sata drive can do >200 mb/s burst speed , right? Probably there was some cache involved somewhere and the nvidia software IDE drivers were doing their thing. Interestingly, the benefit is only seen on boot volumes.

[bing]

Thanks for sharing the detail report here, really appreciate it ! :)

I like to comment particular at the 4 Raptors Raid 0 configuration, looks like either in nF4 or in 3ware, at the STR (sequential speed) graph, they show that the system is blocking their fully capability.

Here how I see it, with 4 Raptors with each capable of STR starting from beginning of drive "approx." 75MB/s downto about 45MB/s right ?

So with 4 of them, it should be started at "about or near" 300MB/s and declining to about 180MB/s at the end/rear of the raid drive. So the slowest part which is at the end of drive should be "minimum" at 180MB/s.

Yours both nF4 and 3ware are showing around 115MB/s "flat" from the beginning to the end. Something is wrong there.

[bwanaaa]

dont know what could be wrong. it was a MINIMAL XP pro install, 6.86 nvidia chipset drivers, latest nvidia video drivers. Task manager does not show ANYTHING sucking cpu cycles. In fact, I never realized how few things one actually needs in task manager for XP to run.

The cables brand new, connections good and no errors seen on checking the drives individually. FWIW, others posting their results show findings similar to mine in terms of speed. of course there was that one post where that fellow showed a burst speed of >600 mb/s but he admitted it was a fluke and his real speed was around 200.

can you direct me to a collection of graphs that show what you mean?

btw, here are the results when i turn off tcq and ncq. not much better, i am still 'FLAT'.

[bing]

can you direct me to a collection of graphs that show what you mean?

Although these following examples are all from intel mobo chipset, but the "true" drive's performance should show you some hint.

Word of precatious, please don't get me wrong, there is no intention to bash non Intel product here, I just want to show you the true drive's performance. Especially from that premium price raptors could do.

Just for sake to straight up this discussion, please ignore the burst speed, average seek time, CPU utilization readings from these examples.
Just watch the starting values from those jaggies reading graph on the sequential reading part. This because of different raid arrangement (matrix raid), so it is not a fair comparison for these values.

Again, I repeat, just watch the HDTach upper screen for the "Sequential Read Speed" part.

Here we go :

- Example 1 -> HERE (http://www.ocforums.com/showpost.php?p=5069769&postcount=624)
You can see this lucky owner of 4 raptors shows the graph that the sequential read speed was starting at around 350MB/s, that shows a really fast which is expected at the beginning of the raid 0 of 4 raptors. These for 3 pics are the beginning part of the Raid volume since it's size only 66GB

Now on the 4th pic, that is the rest of the raid volume starting from location at 67GB to end of the drive, it shows the read speed started from around 280MB/s and slowing down to about 170MB/s which almost similiar with my calculation.


- Example 2 -> HERE (http://www.ocforums.com/showpost.php?p=5092401&postcount=689)

This are the "front part" of Raid 0 volume with 3 (three) Raptors, you can see again, the read speed is started from approx. 220MB/s.
See ? 220MB/s divide by 3 raptors = 73MB/s. Again, proven very close to my calculation.

Again, the same system but this time on the other slower "rear" part of the raid volume -> HERE (http://www.ocforums.com/showpost.php?p=5093878&postcount=692)
Click on the picture named "second raid.jpg", you can see, it ends up near 140MB/s, hence 140MB/s / 3 Raptors = 46MB/s, again, very close to my calculation.


- Example 3, here is my 2 Seagate 7200.10 250GB on Raid 0, these are not matrix raid, just plain Raid 0.

57667

You can see, the read speed started from about 160MB/s downto 80MB/s near the end of the raid volume.
Remember, this are 2 el-cheapo 7200.10 drives, your 4 raptors on those read speed should beat the hell out of mine. :D

Once again, please ignore the burst speed, avg. seek time, CPU in these above examples since these are different system and raid arrangement.

I hope this will show you that what your 4 Raptors capable of. That's all. :)

[shadowdr]

Here is a pic of My NV Raid, same chipset? This is 2x raptors and 2x perps setup as two seperate raid volumes.

[shadowdr]

Sorry wrong picture try this one. I would say somthing is amiss.Raptors are blue and Perps are red.

[tuskenraider]

Just to further agree, there is something limiting the OP's bandwidth based on the flat graph that should be tapered from left to right(from the outer to inner portion of the disk platters). My two Raptors on NF4 RAID0:

http://www.wideopenwest.com/~vacationdave/nf4raid0tach.JPG

[bwanaaa]

well, as you saw, even the raid i ran on the 3ware card was flat. it oscillated, but essentially flat. Therefore the bottleneck is independent of the chipset and somehow related to my xp install. maybe it's related to the fact that i chose to install the nvidia drivers (you know the optional ones) and that when i uninstall, these remain. The only way to know is to REINSTALL windows i suppose.

[bwanaaa]

well i figured out that turning off read ahead cache gives me 40 mb/s more.

[bing]

Basically they're still flat ! Should be around 300MB/s with 4 of that beasts and yours are half of that.

Looking at Tusken's SS with 2 raptors, yours 4 are not much better than his.

Are you sure you've tried all possiblities ? BIOS ? Jumper and etc ?

[bwanaaa]

i wonder what stripe size he uses. i applied 'optimal' in the nv bios. maybe 1k will give me better numbers,


jumpers? what jumpers? bios? what bios settings?

[bwanaaa]

My bandwidth was limited because I had a windows XP pro install using the STANDARD CLUSTER (4K) and the nvidia RAID was set to optimal (64K). Attached are improved numbers.In all cases the raid had tcq, ncq, and read ahead cache disabled in device manager.
2 raptors with a 32 k stripe

[bwanaaa]

2 raptors with 16k stripe





I wonder why the graph for the 32 k stripe oscillates so much?

[bwanaaa]

4 raptors 16k stripe

[bwanaaa]

4 raptors 8k stripe


Interestingly, atto requires a formatted disk. When I formatted the RAID, I get slightly different numbers. See next.

[bwanaaa]

4 raptors 8k stripe formatted but not boot drive

[bwanaaa]

4 raptors 8k stripe as boot drive

[bwanaaa]

so dropping the stripe down to 16k doubles (almost) the bandwidth. 8k gives a little better hdtune results so i think that's the size to use for desktop apps. from what i've read, video work with large files should be used with a large cluster and a large stripe. so i guess the best way to benchmark that is simply by copying large files. and timing that event. anyway, i am satisfied. what is the the theoretical limit for this kind of raid?

[tuskenraider]

Whatever the drives sum of their limits are. Still strange that the stripe size has had that major of an effect on bandwidth. I wonder if it's board/controller combo related that doesn't like 64K for some reason, but at least you "solved" the issue.