Sign in to follow this  
naro

15k SCSI Hdd Benchmark - a bit weird

Recommended Posts

hey guys,

I think that the benchmark results for my 15k SCSIs are a bit weird.

First of all, i shall state my specs:

- Intel C2D E6300

- Asus P5WDG2 WS Pro

- Adaptec 39320A (Dell OEM but flashed with HostRaid BIOS)

- Seagate 15k.4 146gb SCSI hdds (Sun OEM)

My hdds are stored inside Cremax Icy Dock hotswap cage. Each of this cage can hold 3 hdds.

For SCSI cables, I'm using Adaptec rounded U320 SCSI cables.

Results of just 1 hdd:

Cheetah-1.jpg

Results of 2 hdds in Raid 0, stripe size 64kb

Raid0-2-64.jpg

Results of 3 hdds in Raid 0, stripe size 64kb

Raid0-3-64.jpg

Results of 4 hdds in Raid 0, stripe size 64kb

Raid0-4-64.jpg

Is something wrong with my results? Or is it normal?

thanks.

Share this post


Link to post
Share on other sites

I think your results are representative of common experiences with the drives and adaptors in question. I would certainly be looking at running a 2x2 aid0 config per your results.

Share this post


Link to post
Share on other sites

Problem is the multiple drives are not getting a good flow of instructions. Sending the requests to each means that by the time you come back around the disk has rotated past the desired location and has to wait for it to spin around again before reading. Drive read-ahead caching, controller optimisations and software design (pattern of requests) will affect performance. Often happens when reading from disks is faster than the controller can recieve data and send more requests (3x90=270).

Optimise for random access (multiple user load, no read ahead of entire track, immediate execution) will reduce sequential read.

Optimise for sequential read (single thread/app/user, read ahead of next block, pipeline/re-order/batch requests) will slow random access.

Need faster interface and faster controller. Need better adaptive tuning (read ahead, cache).

In theory RAID1 can allow read access similar to RAID0 by allowing read to use both disks (split large request into several smaller requests similar to KB/track and send as a batch). Unfortunately they may optimise RAID0 and/or RAID5 access but RAID1 tends to read from only one disk with single large request.

4KB per request (typical cluster size and OS page size) limits benefits of sequential speed. 512KB per request would be more economical for larger files. Unfortunatley OS tends to have lots of <4KB files which the filesystem does not handle well. Almost need a 2-tier filesystem which allows several small files to be held within a larger block with own header/sub-filesystem. NTFS allows some file contents to be held with the file entry (of the directory entry, 1K?, filename, file attributes, ).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this