Sign in to follow this  
arklab

HTPC Storage Drive – Desktop or Server better?

Recommended Posts

Time for me to seek out pro level advice!

I’m running a dedicated HTPC which currently records four (4) HD television streams while playing one (1) more HD stream back.

I’m soon moving to recording eight (8) HD television streams while still playing one (1) HD stream back.

Current setup: A HTPC with a WD Black 1TB boot drive and a Seagate Barracuda (ST31500341AS) 1.5TB as storage drive.

It’s been working well.

I plan on up-grading my storage drive to a 2TB 7200 RPM 64MB Cache drive to keep up with the new recording demands.

THE QUESTION:

Which drive is better suited to this type of data stream?

A Western Digital Caviar Black (WD2001FASS) desktop drive

OR

A Western Digital RE4-GP (WD2002FYPS) server optimized drive?

Both are the same price, same warrantee, etc., but have different firmware optimizations.

I don’t foresee going to a RAID array (that would make the choice obvious).

So, what do you think, please.

Thanks

Share this post


Link to post
Share on other sites

I'd pick the desktop Black - I don't think the RAID Edition is specifically bad for desktop, non-RAID usage, but the -GP on the end would seem to imply it's a GreenPower model, i.e. ~5400 RPM rather than 7200 RPM. While HTPC drive demands are traditionally rather light, I think 8 simultaneous HD write streams and a read stream might stress a 5400 RPM drive. I think any drive will spend a fair proportion of its time seeking under those circumstances, so minimising seek time is at least as important as maximising sustained transfer rates.

Do some testing when you've got it set up, but you might (depending on the bitrate of the HD streams) find it necessary to keep the Seagate in there as a second storage drive and try to split the simultaneous recordings across both storage drives. It depends on whether you've got room in your case, and what HTPC software you use. I'm not sure if Windows Media Center will let you do this, for example, but Myth might.

Share this post


Link to post
Share on other sites

A Western Digital RE4-GP (WD2002FYPS) server optimized drive?

Euhm, that will almost certainly NOT be the right choice, since it's a 5400RPM disk with aggressive power saving tendencies (can be tamed a bit). You'll want a 7200RPM disk.

Disks aren't made to write multiple streams concurrently, or rather, they can't. They can do two actions, either write sequentially and achieve VERY high performance, or, seek. Seeking costs time and during a seek, nothing can be written.

Writing multiple streams at the same time means that the disks will HAVE to seek to keep up with each sequential part on the disk. Seek times are related to platter density but mostly to spindle speed. So a 5400RPM disk take 3 times longer to do a seek them a 15.000 RPM disk will. Thus giving the 15.000RPM spindle a higher random I/O, while not necessarily giving it a higher MB/sec.

This is also the reason a 300GB 15K RPM disk can have the same sustained sequential transfer rate as a 2.0TB 5400RPM disk. The 5400RPM disk needs 3x the platter density to negate the 15K RPM's spindle advantage. The 15K will always win in seeks though, because it can just reach a certain sector faster.

Anyway, I'm getting off my point.

Since you are writing multiple streams and your software probably is not intelligent enough to mix these on disk (mixing them or separating them both have their advantages either for writing or reading) I'm going to assume that they are written into separated files in a non-fragmented way. That means you'll have to handle a lot of seeks while writing this so your spindle speed is important. Cache will also greatly benefit you as NCQ will.

Which brand to take, that I can't really tell you. More cache is good, so the 64MB variant you mentioned seems like a good start! Also multiple drives can greatly enhance how many streams your able to handle, again in relation to the above story.

Edited by Quindor

Share this post


Link to post
Share on other sites

but the -GP on the end would seem to imply it's a GreenPower model, i.e. ~5400 RPM rather than 7200 RPM.

Oh, gads, is my face red!

I had completely missed that point and been assuming it was a 7200 RPM drive.

Once again bitten by the old RTFM adage, but "Specification" in this case.

Thanks

Share this post


Link to post
Share on other sites

Also multiple drives can greatly enhance how many streams your able to handle, again in relation to the above story.

OK, but are you referring to a RAID here?

Please explain a little more.

PS - the streams are MPEG-2, and generated from Windows 7 64bit Media Center, if that is pertinent.

Share this post


Link to post
Share on other sites

No, you would want the opposite of RAID. Or more specifically, no RAID.

Lets say a typical HD MPEG-2 stream is 2.5MB/sec (20mbit/s), 8 of them would barely hit 20MB/sec. Even with all that seeking even a 5400 RPM eco drive would be able to keep up fine.

Share this post


Link to post
Share on other sites
Since you are writing multiple streams and your software probably is not intelligent enough to mix these on disk (mixing them or separating them both have their advantages either for writing or reading) I'm going to assume that they are written into separated files in a non-fragmented way. That means you'll have to handle a lot of seeks while writing this so your spindle speed is important. Cache will also greatly benefit you as NCQ will.
This isn't usually a concern while only writing to the drive. Recording software tends send writes to the OS in fixed sizes, such as 1MB. The files are often first created very small on the drive at the first available larger space, so they are created next to each other. And then they are added to in chunks, with the OS buffering quite a bit beforehand. The result tends to be a fast sequential stream which alternates between the video files being expanded. Writing 8 simultaneous streams like this isn't hard because the data in the files is all interleaved together on the disk.

The problems are:

1. Fragmentation. Delete one file, and the available space is suddenly extremely fragmented. Writing after that can cause quite a bit of jumping around.

2. Reading back at the same time as writing. As you point out, this is a completely separate steam. Writing several streams at once will cause the write points to get steadily further from the read points on the platters, so seek times will steadily increase. If your OS's I/O scheduler is good enough then it could might handle buffering really far on the read ahead while queuing up write, and the alternate. Add in fragmentation though and things get really complicated.

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