lousy raid0 performance mystery

dtivofun

Hey guys, take a look at these ATTO scores. Does anyone know why they are so low? Things are respectible up until 16 kB, but what happens between 32 - 1024 kB??



This is a new installation of a Promise SX4000 w/ 128 MB cache. The array is raid0 with a WD1800JB and a WD2000JB. Stripe is 16 kB with a cluster size of 16 kB.

This is killing me! I thought the performance would be much better...

My specs:

AMD T-bred 1800@1666, 166 FSB, 512 MB PC2700, ASUS A7N8X-Dlx, Promise SX4000 w/ 128 MB RAID0:WD1800JB+WD2000JB 16/16, GeForce4 Ti4200 64 MB, Sony DRU-500A

Ageek

By settign the cluster size so small you are tuning for smaller file sizes. If you have lots of of big pictures you CAN set a partition(logical drive) up with larger clsuters and have it work, or a whole hard drive if you collect movies. At that point the larger files might run faster.

HOWEVER, check a couple things that might not seem to matter, ok?? First, make sure you have an ATA\66\100\133 cable hooked to the HDs. Those drives will run in ATA\33 mode if they are hooked up to an older 40 conductor cable. The wires will look to be about half the thickness of the older HD and CD-ROM drive cables. The drive you are benching is using the buffer to read and to write, as well, from what I can see, so what happens is it may be pending writes.

In the real world for average use this will not matter too much, as it pends until the whole file is sent if the file is less than 8 MBand then bursts it. The benchmark you are using tiems from start of write request, not when the drive starts writing, so it is counting the transmit time for the whole file rather than a small block which then is written while the drive takes more data and fills its buffer. Ifyour bench were to feed it 32-64MB and bench it, then a diferent story would show up, as then the 8 MB buffer comes into its own.

The seek for the bigger drives is no different (so littel it does not matter) than the smaller JBs(less than a tenth of a millisecond). But with GB sized continuous data flows like moving whole data trees or large files in one chunk the actual write time is much better than smaller non-JBs with smaller buffers.

To really get lots better smaller file size (sizes in that benchmark range) speed differences you need a drive that rotates a lot faster and moves the arms that support the heads faster. The drives that do that limp if they are not hooked to controllers that handle faster throughput. Things Like SCSI II and III drives, the faster rotating true SATAs that also seek faster in part due to the way the heads are made and the stepping is done faster with newer designs in head (and the arms that support the heads) movement.

No one of these (buffer, arm movement, or rotational speed) will in and of itself make for a much faster drive for all file sizes. All of them togetehr plus a very fast controller on a very fast box will do that. But you will pay 2X to 3X for such drives and what they need to really fly.

I can tell you that for some operating systems otehr than those that use NTFS, these WD JB series drives LIKE being run in DMA mode especially for reading. So, if you do not have XP or Win2K you might try putting them in DMA mode and see what happens to the benches.

Wolfman

You also using two different drives, not a good idea. Raid 0 works best with a matched pair

Tex

I have not looked at the options for that controller in a while. Shoot me a link and lets take a look as the scores are worse then for a single drive. 16k is usually fine for IDE raid btw...

What driver version etc...

Tex

dtivofun

Thanks for the info guys. I played around with things and found that setting the stripe size to 64k drastically improved things in ATTO. The transfer rates are now monotomic with increasing size. So, now from 32 to 1024, I get about 51.2k for Write and 86.6k for Read. Cool!


BUT, it made HD Tach results worse on reads:

16k stripe size in HD Tach:

Read: 57.0k max, 4.4k min, 48.6k avg
Write: 33.0k max, 4.0k min, 22.8k avg

64k stripe size in HD Tach:

Read: 38.5k max, 3.1k min, 30.2 avg
Write: 44.6k max, 4.7k min, 28.0 avg


So this begs the question, which stripe size would you recommend? 16k or 64k? What translates into real-world performance? My main objective here is responsiveness from WinXP. 2nd is probably large-file MPEG manipulation and DVD burning.

Thanks again, guys.

btw, I'm using the latest BIOS, WinXP drivers, and PAM utility from the Promise website.

Tex

hdtach has little to do with real life performance. It bypasses the os and filesystem.

I can probably help you bump your writes up 10 to 20,000

Tex

Rob

Tex is the raid master
I couldn't offer any assistance that Tex wouldnt think of. The only thing I could add is I'm seeing simular performance from SINGLE drives. I have more than one machine reading 50+M from one IDE drive without any caching controller.

Get with Tex, hes your man

dtivofun

Well, I certainly would appreciate any help that you could give, Tex. Let me know what the next step is.

When I get home tonight, I was planning on moving both drives to the NForce2 onboard controller and rerunning ATTO so that I can get a baseline. I'll post results when I get them.

Anything else that I could try?

Tex

I have owned a half dozen promise raid controllers but never a 4000... But every one I messed with responded well to having the pci latency of just the controller not the whole bus raised. Some times raised a bunch.

Also... what kind of options does that thing have in the bios for cache options? How does it cache the reads and writes>

Tex

dtivofun

Tex, my motherboard does not have any options in BIOS pertaining to PCI latency. There may be utilities to tweak those values for the NForce2 boards, but I haven't seen them yet.

On the SX4000 itself, you can select either Write Through or Write Back mode for the cache. I selected Write Back (the default) for speed.

The only other options, which are on a per array-basis, are 16, 32, or 64k stripe size.

Swordsman

You can download Powerstrip from:
http://www.entechtaiwan.com/ps.htm

(use the shareware version)and install it and set the latency of the controller to whatever gives you the best performance. once you've installed it do the following:

1. Left click the "TV" in the sys tray;
2. choose options
3. adapter information

Then, find the up/down arrows in the upper right corner of the window and scroll to your adapter.

Then, look for a box with a check in it labeled "read only" and uncheck it. You can then change the latency for the adapter. The changes will take place real time and you can then re-run ATTO and compare values to see which gives you the best performance. Tex suggests that you don't make the changes permanent until you know your system will reboot with them and give you the performance you want.

Otherwise, you can look for Tex's latency primer with pictures on this site somewhere, I think!!

S!