Render Drive??

SecondWind-SK wrote on 8/6/2014, 9:47 AM
I'm working up a new computer. SSD for operating system and programs. I typically use external spinning drives for for all project files. Is there an advantage to having a second SSD for projects, then off loading the project to external HD after project is done? I seem to recall reading that some people use the second SSD as a 'render' drive. Thanks for any comments.

Comments

Chienworks wrote on 8/6/2014, 11:00 AM
You can save some render time, a very very tiny bit of time, by doing this. However, you'll then use up that time savings and more by copying it to the regular HD afterward. Considering the whole process of render -> file -> external HD, you'll actually accomplish it faster by rendering to the external HD than to the SSD first. I would also advocate against abusing your SSDs with unnecessary writing.

On the other hand, the time difference we're talking about is probably a few mere seconds compared to hours long renders. Not enough difference to care about either way.
OldSmoke wrote on 8/6/2014, 11:28 AM
SSD or not is a different debate. However, you should always read from one drive and write to another drive. This would mean that all your project files are on a separate drive from your render drive. SSDs as project drives have the advantage of faster reads which comes in handy for multicam projects and 4K editing. A top setup actually uses a drive or raid array for each camera source and then writes to a separate drive. Assuming you have your project files on a separate drive, the savings on time between writing to a SSD or spinning disk are minimal even for 4K files.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

SecondWind-SK wrote on 8/6/2014, 11:40 AM
Thanks everyone. Really appreciate the info.
Steve Mann wrote on 8/6/2014, 12:43 PM
I've done some experiments in that area, including a 10Gb RAM drive. My conclusion was as expected, the disk I/O speed is a very minor component in the overall throughput. Your mileage may vary but my workflow is with HDV files. The baseline was a second hard drive on the editing PC, a typical configuration. I recall that the baseline render took about two hours. No matter what combination of SSD or RAM disk I used for the source media or the render destination, the delta was always measured in minutes. The best combination was less than ten minutes. Which as Mr Chien says above, is completely consumed when the project gets archived to HDD.

BTW - one of the combinations I tested was using an external USB2 HDD for the project files, and the rendering time was less than five minutes longer than the baseline.

Remember, YMMV - My workflow is with HDV (m2t) files.
rmack350 wrote on 8/6/2014, 1:31 PM
This sort of question repeats itself. In general, writing the output of a render is usually constrained by the speed of the render/encode job, so if you can render faster than your drive can write then there's a speed advantage to getting something faster.

That's a big "if". Maybe the best way to set a practical benchmark would be to time a straight file transfer from one SSD to another. Use a media file that Smart renders in Vegas and then try a comparison between a simple file copy in Windows Explorer vs a smart-render to the new drive in Vegas. Once you have those two numbers you can start comparing non-smart render/encodes to various media. I predict that you'd find that you don't normally need to encode to an SSD.

A decade or more ago, when a Pentium III was still standard fare, I compared rendering to a 7200 RPM disk on a firewire buss to rendering the same output to an IOmega Zip disk on a parallel port (it was a lark). The times for each were very close, which is to say that the time was almost entirely consumed by rendering, not writing.

Rob
VMP wrote on 8/6/2014, 1:50 PM
This is a discussion we had here a while ago:
SSD speed for rendering with Vegas and memory.

I have also placed some screenshots of test runs between SSD's and HD's.
As others have stated the transfer/write speed also depends on your encoder and codec.

VMP
skosh wrote on 8/6/2014, 8:05 PM
Take what I have to say with a grain of salt as I am a neophyte in regards to video processing. However my example perhaps may illustrate the same problem and that is bottlenecks. At work(not video/database info) we had very old servers(5 years old) to process data and the infrastructure folks suggested we needed fiber channel drives to speed things up. So the nice fancy new equipment was installed and moving files around was a breeze however they were stumped when the processes that were supposed to be sped up were not. The problem was not I/O related as the data streamed(processing) from the servers was slow. So what eventually happened.... they purchased faster servers and all of the sudden things were faster. :) I'd say the old drives were sufficient even with the new servers. So if you have a slowdown anywhere between I/O in your process you are not going to gain significant performance as there is an issue with throughput.
musicvid10 wrote on 8/6/2014, 10:21 PM
Completely agree with Steve Mann.
For most of us, drive throughput will never bottleneck the system.
Chienworks wrote on 8/6/2014, 10:29 PM
I'll also mention that hard drive throughput and read/write speed has continued to increase dramatically over the past few years where almost every other part of the system has pretty much plateaued now. So, compared to the CPU, hard drives are MUCH faster now than they were a few years ago.

And drives from 15 years ago were faster than the video rendering process.
musicvid10 wrote on 8/6/2014, 10:33 PM
Even grandma's EIDE will transfer over 200 Mb/s.

john_dennis wrote on 8/7/2014, 1:32 AM
In this thread, working with uncompressed sources was covered [I]ad nausea[/I].