Hard Drive Setup for Vegas and Platinum

Chienworks wrote on 6/19/2013, 9:11 AM

The SSD should be reserved for uses that are mostly read with very little writing, such as OS and program files. You should never store work-in-progress on it, as the more writing it gets the faster it will wear out, much faster than conventional hard drives. Any data and video files should be on conventional drives.

Any conventional hard drive built in the last 15 years can read and write data *WAAAAY* faster than even multiple HD streams, so the rest of your question is mostly moot. At the end of the day it will make almost no difference how you set up your drives and where you store things. In real world tests, the differences in setups add up to a few mere seconds out of a full work day.

2TB drives are so cheap now, why would you bother with 1TB drives at all? Also, i've switched to using all WD green. They're still much more than fast enough for video, they're a lot cheaper, and they run cooler so they will last longer and use less power. Black drives are really only a benefit in large mission critical server operations where you need hot-swappable RAID. For other uses they're not worth the expense.

musicvid10 wrote on 6/19/2013, 9:22 AM

". . . as the more writing it gets the faster it will wear out, much faster than conventional hard drives."

Why is that, Kelly? What is the useful life of an SSD that is being written to, say for video rendering?

Chienworks wrote on 6/19/2013, 11:07 AM

Early SSDs had a useful limit of about 999 write cycles. The first commercially shipping ones were about 9999 cycles. Now they're usually rated for 50,000 or so. Note that this isn't 50,000 file saves; it's that each byte on the drive can be written to that many times before it's likely that it freezes up and doesn't work anymore.

That may seem like a lot, and if you're using it for video file storage you may never reach it. But if you're using it for storing lots of smaller files that change often then it's quite possible that you could reach that number on some specific areas of the drive rather quickly. Of course, the newest generation of SSD drives have controllers built in that spread the writes out all over the surface in order to minimize this, but, why risk it?

Conventional hard drives can survive billions of writes without degradation.

As far as speed goes, it is true that an SSD *CAN* perform hundreds of times faster. But, how often is this a benefit? Maybe when you're making a straight copy of a file it will matter. In general though, what most of us are doing is editing, rendering, and encoding. In these cases most of the time we're waiting for Vegas to tell the CPU how to modify the data, and the read/write time of the drives is a miniscule fraction of the total time. Speeding up a miniscule fraction isn't going to have any noticeable effect compared to the CPU time.

added ... Amusing side note: as i was typing this a cow-orker sat down next to me and asked basically the exact same question about the life of SSD drives.

DavidMcKnight wrote on 6/19/2013, 2:57 PM

Interesting that VideoGuys recommends an SSD specifically for a render drive. This article, about a third of the way down.

videoITguy wrote on 6/19/2013, 3:29 PM

I have dealt on a professional basis with Gary and the boys at VideoGuys for many many years. Over that time I have learned that they sometimes have a really good sense and at other times, well, let's say they just don't make sense. When you read the entire passage as posted and shown in your link, you begin to realize that in context the SSD paragraph gets tossed in as an afterthought. How much did that have to do with their last minute edit of the html on their server? hmmm?

There are actually some Vegas forum members who have tested this weird concept that an SSD drive chosen as an export surface is going to make a difference in renders! Ha, lo and behold, the truth is in the pudding!!!!

Where codecs that are heavily processor intensive (take your pick GPU, CPU, and both) and are the most favored among hobbyists of the user base in Vegas Pro app - DO NOT BENEFIT from this setup!
WHY?

But on the other hand an avi uncompressed delivery in a pro shop delivered off of RAID 0 source to a waiting SSD surface may benefit! WHY?

pcunite wrote on 6/20/2013, 1:33 AM

I do all my work on an SSD now. Even 512GB is cheap enough if want the speed benefits.

Chienworks wrote on 6/20/2013, 8:59 AM

"Where codecs that are heavily processor intensive (take your pick GPU, CPU, and both) and are the most favored among hobbyists of the user base in Vegas Pro app - DO NOT BENEFIT from this setup!

Very simple. When the rendering process is CPU intensive, the CPU is the bottleneck and the drives just sit there waiting most of the time for the CPU to have more data available. When the rendering process is NOT CPU intensive, the drives are the bottleneck and the CPU mostly just sits there waiting for the drives to be ready to accept more data.

In most of today's workflows, the first option is far more common than the second.

OldSmoke wrote on 6/20/2013, 11:03 AM

Here is what I got on my VP system:
C: 1x SSD 256GB for OS
D: 2x HDD in RAID 1 for Storage 2TB
E: 2x SSD in RAID 0 for Projects, 512GB
F: 2x SSD for Render, also contains all the temp folders for Vegas, 256GB

D: and E: are getting a bit too small and I am looking now into a RAID 10 and depending on the performance, I might drop E: and just work of the RAID 10. That would save some time in my workflow.

I first transfer all the footage to the storage, copy to a folder on the project drive and work from there. Once done, the whole project gets archived to the storage, I use Vegasaur for that.

While rendering to SSD or HDD doesn't really make a big difference ( I just had that those SSDs lying around), working from a very fast drive makes a big difference. Especially multicam projects and high bitrate footage run better this way and the timeline runs on full fps on Best Full or a setting lower.

EGS wrote on 6/23/2013, 11:12 AM

"You should never read and write to the same drive when rendering! "

Is this true? I've rendered to the same drive as the edit source (WD Black) without any issues. The CPU is the bottleneck.

OldSmoke wrote on 6/23/2013, 1:23 PM

Never is a strong word. It depends on all the components in your system and for some, the CPU is NOT the bottleneck. I for one don't do it because I don't want to "stress" the storage drive too much by rendering and erasing constantly; I rather stress a dedicated drive that doesn't contain all the raw footage which is also a reason why I have a dedicated project drive too. Also reading rendering a multicam project from the same drive does slow things down.

videoITguy wrote on 6/23/2013, 1:28 PM

EGS - please don't panic. You referenced the following comment withhout context: made by : VidMus on Date: 6/19/2013 2:57:33 PM--"You should never read and write to the same drive when rendering! How much that will slow things down is debatable but the extra wear on the drive heads having to go all over the drive to read and then write will greatly shorten the life of the drive."

The key word here "debatable (sp)". It is a matter of degree- if you are only occassionaly using your drives and you trade in hardware every 3 years - then don't worry. If your codecs that you choose to render to destination are CPU intensive - then don't worry.

For those of us on 24hr production schedules using drives to render continuously and the codecs we use are not so CPU intensive...then you are talkin the standard pro shop. Drives set up as source and destination and likely using RAID configurations delivering really large files.

Chienworks wrote on 6/23/2013, 10:57 PM

If you have source media from more than one file being read at the same time then the heads are going to be bouncing around anyway just reading the source! The extra bouncing around for the writing is close to inconsequential.

As far as speed is concerned, i've compared rendering relatively long projects from one drive to another, and on the same drive. The difference in time wasn't even noticeable compared to the length of the render, something on the order of a few seconds per hour of project.

mean_streets wrote on 6/28/2013, 8:40 AM

A couple of points to keep in mind with SSD's. First, the lifespan of SSD's are really very good, and I don't think that they need to be "coddled" in any way by not using them to write to. Anandtech has some good info on this. See the Intel SSD 330 review there. I don't think anyone will keep a drive in a performance system long enough for it to wear out.
The second point is that SSD's with Sandforce controllers have poorer performance with uncompressable data read and writes (such as video files), because the controller compresses data as it is stored. At least this was the case up until about a year ago when I last shopped for a drive. Again, I remember Anandtech having some good info on this.

ingeborgdot wrote on 9/5/2014, 7:58 AM

Okay, so let's say you have 1 SSD and 2 2TB WD Black. No raid of any kind, sorry. My big question is of all the preference settings etc. would anyone be so kind as to tell me what they would use for general tab and temp files folder, where you would keep your capture folder, where you would render to and any other pathways you think need to be created. Or does it really even matter? Thanks.
C: SSD
D: 2TB WD
E: 2TB WD

videoITguy wrote on 9/5/2014, 1:34 PM

ingebor... in your planned C, D, E - C is the boot drive for the OS - meaning a fast boot service - but on Win7 or better that is not important.
D and E are your source and destination drives - for example D is the source files - E is the rendered output of projects. Unless you have some extraordinary requirements like multi-stream uncompressed files for projects - then this all is not going to matter a whoot.

NCARalph wrote on 9/6/2014, 10:59 AM

I've got a setup with a 4 core I7, 12 GB RAM, an NVidia 570 GPU, a RAID drive and an external USB 3 drive and have actually done some testing with different disk configurations. I used to have an EIDE drive which I replaced with the USB3 with no change in speed.

There is almost no difference in rendering time if I use RAID to RAID , RAID to USB3, or USB3 to USB3. Looking at the CPU, GPU and disk utilizations it's easy to see why, the disks are running at very low utilizations, the CPUs are pinned and the GPU is running at about 50%.

My conclusion is that unless you have a very very fast computer the disks aren't even close to the bottleneck. (I also need to get a faster CPU someday).

WRT not reading and writing to the same disk - The studies I've seen have found no correlation between activity and failures. The main issues are the manufacturer (Hitachi seems the best) and age. In any event, the number of reads and writes for a render is not very high, assuming you've got enough RAM to avoid swapping, since the source files are read once each and the output file is written once.

videoITguy wrote on 9/6/2014, 11:19 AM

That's right NCARalph, disks are not the bottleneck when you have to work with highly compressed formats - because it is the CPU cycles that are determining decode and encode with the type of codecs involved. This is the main issue in rendering.

However, there is a much different case if you are capturing video thru a non-compressed file type - say moving a 10bit stream directly off camera head into a computer file format. Then disk speed is everything!

One other case should be pointed out - the flow of multiple elemental video and audio streams as uncompressed as source to a preview or render stream that is also uncompressed...in this case disk activity will be very volatile and a measure of performance.

John_Cline wrote on 9/6/2014, 5:44 PM

Interesting work that IBM is doing to replace hard drives and SSDs:

IBM wants to kill the hard drive that it invented.

john_dennis wrote on 9/6/2014, 10:25 PM

I've been reading about the progression of memory and storage for 40 years. Some technologies made it and some didn't for one reason or another.

In the '70s, I was fascinated with bubble memory.

In the link under Further Applications:

"IBM's recent work on racetrack memory is essentially a 1-dimensional version of bubble, bearing an even closer relationship to the original serial twistor concept."

NCARalph wrote on 9/6/2014, 11:28 PM

@VideoITguy
Sure, that's also true, however this being a Vegas Pro forum, that's not what we're talking about in 99.999% of the cases.

Steve Mann wrote on 9/7/2014, 8:37 AM

I remember working with bubble memory. It was so slow and unreliable that we dropped it and went with EEPROMS.

SSD Life - yes, there is a finite write limit, but the test labs at PC Week have been using the same SSDs for years and haven't exhausted one yet. They doubt that the average user could ever teach the write limits.

Note that Vegas makes the temp folders it uses in the boot device by default.

I built a new system with two SSD's, one for the OS and programs and the other for editing. I also had two 2Tb drives for longer term storage. It made practically no difference if I rendered to the SSD or to the HDD - mere seconds from an hour render.

HDDs are cheaper. I backup and archive on HDDs all the time. Projects from ten years ago are still readable, but I have been moving all my IDE drive content to SATA drives, which refreshes the content.

SSDs are quiet and indestructible. (As opposed to dropping a drive from the workbench).

Both have their benefits and shortcomings, but I doubt that you will be able to buy an HDD ten years from now. Just try to find a floppy disk drive and discs today.