Continued from http://lime-technology.com/forum/index.php?topic=4581.0

 

Joe L. and WeeboTech, thank you both for your responses.  You have certainly clarified the issue for me.

 

So, if I understand it correctly, in order to build an unRAID server optimized for speed all of the drives would have to be 7200 RPMs, or 10,000 RPMs, or any fast speed so long as they all were the same.

 

 

This is partially correct.

Optimizing unRAID for maximum parity speed will require all drives to be as fast as they can be.

Optimizing "segments" of the unRAID server will require "some" of the drives to be as fast as they can be.

 

There are two scenarios.

In my case, Part of my array is the local network file server for many small files, photos, downloads, pictures, music.

Part of the array is the movie media storage.

 

Having a server with a mixture of 7200 RPM, 5900 RPM, and 5400 RPM drives will always result in somewhat slower write and parity check performance in some cases (when one of the slower data drives is being written to).

 

Slower write speed to the drive with the slower write throughput. I say it this way because a modern 5400 RPM drive can be faster then an older 300GB 7200 RPM drive (I have a pair that reveals this).

 

In all cases, parity generate or check speed is dictated by the slowest drive in the array for the segment it is used for parity calculation.

 

My server currently has a mixture of 7200 RPM and 5400 RPM drives.  If I understand the situation correctly, I surmise that the only benefit of having a 7200 RPM parity drive is that during a write to a 7200 RPM data drive the process with go somewhat faster, since the two disks can 'sync up'.  The same would apply to the portions of the parity check in which both the 7200 RPM parity drive and a 7200 RPM data drive are being read.  I should therefore expect fluctuation in the reported speed of my parity checks (which would explain why my parity checks generally don't take as long as they initially say they will, if the first data drive to be checked happens to be a 5400 RPM drive).

 

Yes, in addition, Consider that if you have a 7200 RPM high throughput parity drive and the rest are slower drives, then the latency to finish writes on multiple drives is diminished.

 

This was my issue with torrents.  All drives were 5400 rpm. write speed on torrents was painful whenever I updated another drive.

However, when I updated the parity drive to 7200 RPM, the system did seem to be faster.

When I updated the torrent drive to 7200 rpm, all my latency issues went away.

Interesting.  I also use my server to store/backup small files like documents and pictures, but I access these files so rarely that I didn't give them the 'privileged' position on a 7200 RPM drive.  My main concerns are TV, Movies, and Music, all of which don't seem to care where they reside.  So I really use my 7200 RPM data drives for the files I use the least, since I would rather have the power savings of a slower drive while keeping it spun up for hours to watch movies or listen to music.  Some day (eventually) when I set up torrents on my server, I'll keep in mind to use a 7200 RPM drive for downloading.  Does it matter for seeding as well, or not, since that is just a read operation?

 

Now if unRAID could only get over this Big Kernal Lock issue so my music playback isn't constantly interrupted....

 

Thanks for the info, WeeboTech.

Some day (eventually) when I set up torrents on my server, I'll keep in mind to use a 7200 RPM drive for downloading.  Does it matter for seeding as well, or not, since that is just a read operation?

For seeding, What matters allot is RAM, then hard drive speed.

There are allot of random reads for seeding, so having fast drives helps.

It helps a great deal when downloading. You want to get files as fast as possible just in case someone logs off.

In addition, there are going to be allot of random writes all over the place as downloads via torrent are rarely sequential.

It usually downloads in the least seeded ratio to bring more seeds to the segments that do not have as much coverage.

After a download, the whole torrent is re-read and hashed to double check it's integrity.

This is where a fast hard drive matters. If you spend too much time hashing, some of the TCP connections may drop from inactivity.

It all depends on how fast you have rtorrent throttled for. I have max download speed, 100-300Kb/s upload speed.

When higher the system works a bit hard.

 

I download my torrents to the 'cache' drive, once it's seeding it gets moved into the array.

As per my thread here http://lime-technology.com/forum/index.php?topic=4556.0, i had a 7200rpm seagate 1.5tb drive as my parity disc. Was getting 9MB/s tops when transferring to the protected drives. Changed to a 5400rpm Samsung 1TB drive and write speeds doubled to 18MB/s.

 

Yes logically 7200rpm parity drive makes sense but in practice I guess its not always the case.

 

I've moved the Seagate drive to my main system and its performance there is stellar btw so there was nothing wrong with the drive itself, it just didnt work well with unraid.

As per my thread here http://lime-technology.com/forum/index.php?topic=4556.0, i had a 7200rpm seagate 1.5tb drive as my parity disc. Was getting 9MB/s tops when transferring to the protected drives. Changed to a 5400rpm Samsung 1TB drive and write speeds doubled to 18MB/s.

 

Yes logically 7200rpm parity drive makes sense but in practice I guess its not always the case.

 

I've moved the Seagate drive to my main system and its performance there is stellar btw so there was nothing wrong with the drive itself, it just didnt work well with unraid.

 

This is very interesting, I've had the opposite experience in going from 5400 WD to 7200 RPM Seagate.

Seems like there is an issue with the cache and firmware's use of it. Mind posting what firmware the Seagate is at?

Also which model of the Samsung?

This is very interesting, I've had the opposite experience in going from 5400 WD to 7200 RPM Seagate.

Seems like there is an issue with the cache and firmware's use of it. Mind posting what firmware the Seagate is at?

Also which model of the Samsung?

 

The Seagate was a 1.5TB ST31500341AS with the CC1H firmware. The Samsung is a HD103SI spinpoint eco green drive.

Interesting article http://www.tomshardware.com/reviews/2tb-hdd-energy,2371.html

There has to be more to unRaid write performance than the usual RPM and Cache-Buffer sizes.

 

Talos's Seagate drive benchmarks 20% higher than the Samsung yet unRaid shows a 50% improvement in write throughput moving to the theoretically slower drive. His Samsung green drive benchmarks around the same as my older gen 7200 rpm Samsung, yet I see 28MB/s vs his 18MB/s (Teracopy). My older still 7200 Seagate drives benchmark around 20% less than my Samsungs and yet only manage 18MB/s under Teracopy.

 

I'm waiting on level two MB testing completing (14 days and counting) then I'm going to do some mass HDD testing with as many HDDs as I can lay my hands on.

 

So far I have the following HDDs to test, Samsung 103UJ, 103SJ, Seagate ST3320620AS, ST3500630AS, Western Digital WD3200AAKS. I'm fairly sure I can borrow a few other makes, speeds and capacities of hdd. 

 

I have a three bay hot swap cage and will connect up the following:

 

1 bay to mb (sb700)

1 bay to pci sil3124

1 bay to pci-e sil3132

 

Test set 1, 1.4GB movie file. Dvd rip.

Test set 2, 650MB collection audio files. Cd audio

Test set 3, 4.5GB movie file. Dvd

Test set 4, 35GB movi file. blu-ray

Test set 5, 128MB mp3 files. Mp3 album rip.

 

Test procedure.

 

Populate each bay with a hdd.

Pre-clear each drive, generate parity, note parity speed. Copy each test set to each drive, note teracopy throughput.

Fill each drive 50%, re-test each test set.

 

Stop array. Move each hdd 1 bay, pre-clear each drive, generate parity, note parity speed. Copy each test set to each drive, note teracopy throughput.

Fill each drive 50%, re-test each test set.

 

Stop array. Move each hdd 1 bay, pre-clear each drive, generate parity, note parity speed. Copy each test set to each drive, note teracopy throughput.

Fill each drive 50%, re-test each test set.

 

Each test set will be copied from xp, w2k3 and w7 clients, if after the first harddrive tests all clients are consistent, i'll continue using a single client.

 

Hopefully I can blag another four drives to make three harddrive test sets.

 

I'll test run a hd103uj which is my current parity drive, any drive that performs better, I'll then run as a parity drive and re-test the fastest and slowest combinations.

 

Pre-clears will have to run overnight so it'll take a while to fill the full test matrix, I'll try and locate some benchmark data for each hdd also.