To SSD or not ?

[asik1]

Scubbie, I don't do 4K.
When I build this current system ~May2017 with system SSD and 8GB, I set the page file to only 500MB.
Overall I didn't see any breakthrough, over my older dead build, in rendering speeds.
Most my projects were and still render at ~playtime to X2 that.
I never saw memory choke.

[tletter]

Whilst I don't have any specific figures to hand, I know that rendering content from a 4K source works far quicker when it is on the SSD than the HD.

I regularly render 4K videos and haven't noticed this "far quicker " rendering. Using a SSD as the boot/OS/programs drive will increase performance, however, that's just general computing, not really anything "editing" specific. VS is not I/O bound whilst rendering.

Without metrics to support claims of "far quicker " rendering, this discussion is subjective and subject to the placebo effect delivering "far quicker " rendering.

tletter
https://www.youtube.com/user/tletter

[Davidk]

SSD improves disk level performance. The programme is stored on disk, and only part of it is in main memory at any one time. If you are rendering using large clips, a lot of clips or both, accessing them on disk for rendering purposes will gain benefits if the disk is SSD. If you have oodles of RAM - enough to pull the program and all the contents of a project file into RAM before rendering starts - then you won't see a benefit from SSD during edit or render. Most people have 8Gb, but I read a post once where the PC had 32Gb of RAM, and the report was that VS ran like a ferarri - zipped thru everything. But most Pc's physically can't have that much RAM installed.

[Scubbie]

Certainly what you say is true DavidK. The more RAM available, the better the performance you are going to get where heavy data files (i.e. large video files) is concerned.

I do watch the disk & SSD access sometimes and it does vary from project to project depending on content. Certainly, if this laptop could take 32GB I may have gone to that level at the time. I hope that you would agree with me that for anyone who intends to do a lot of video editing, that they should perhaps consider a variety of upgrades to suit their budget and requirements.

A friend does a lot of photogrammetry (making 3D images from still photography). The dedicated computer used has multi-processors, 2 high-spec display adapters, drives that are faster than SSDs and 96GB RAM at the last count. A single project can take weeks to process. If he does it wrong, the RAM runs out after a couple of weeks. I think this kind of spec sounds great, but a little OTT for what I'm doing with videos.

[tletter]

If you are rendering using large clips, a lot of clips or both, accessing them on disk for rendering purposes will gain benefits if the disk is SSD.

VS is CPU bound and not I/O bound whilst rendering, which you can see by looking at a performance monitor during rendering. However, if you have metrics to support your assertion then it'd be interesting to see.

For those of us with limited funds, these funds should be directed to where the actual bottleneck is whilst rendering.

tletter
https://www.youtube.com/user/tletter

[OBB]

Went to SSD's when they first came out... and I've never ever looked back!

: )

[tletter]

I read a post once where the PC had 32Gb of RAM, and the report was that VS ran like a ferarri - zipped thru everything.

It would be interesting to see metrics to support this conjecture as watching a performance monitor when VS is rendering shows that VS isn't particularly memory intensive even when rendering 4K videos. However, it is CPU intensive but unfortunately not GPU intensive.

tletter
https://www.youtube.com/user/tletter

[Davidk]

As to metrics, I was simply reporting what users had posted about, the context of VS in 4Gb RAM seems to run slowly. This was a report about what happened with lots of RAM - and it was probably a gaming OPC to be able to fit that much.
BUT actually it is memory intensive. The amount varies with the type of memory tho.
For example, disregarding the OS and any pagefile+memory heap it needs, VS therunning programstill has most of it out in storage - as rendering needs parts (for the program, eg a filter or object; or the next clip) they are loaded. Every element (clips, music, voiceover etc) of a vsp has to be read from storage memory, and the higher the definition the larger the files are, and the more memory reads that are required. And conversely the processed output needs to be written somewhere too.

If all the vsp components are stored on an HDD, then read and write access times are relevant. If the files are defragmented on HDD then wait times are minimised, but every access has it in some measure. Add up the number of reads and/or writes done and the time involved is large.
If the PC has a lot of RAM, more of the program and vsp data can be loaded into fast access RAM, and the speedy result in processing time should be obvious. Nevertheless, every access to HDD storage for program or project data has a wait time.
If the PC has it's main store as an SSD, then any storage wait times are basically removed - all that's left is the time to change an address.

Metrics measuring cpu versus memory usage may well favour the cpu in terms of operations - it is after all jumping around in memory doing it's thing. But it takes a lot of cpu cycles to "match" the wait times that modern HDD have - read time average on the size of drives common in laptops is 6.5ms - time from issue of request to get 1st data back. How many cpu cycles could you pack into 6.5ms? Assuming nothing else caused a delay - rough maths indicate that a cpu running at 2ghz could execute 3.3million cycles in the time it waited for one response to an HDD disk read. In terms of events, no wonder a metric program that counts those shows activity favouring the cpu - but that doesn't mean the program is compute bound, but rather that faster memory would speed the entire process up.

[iNate]

As to metrics, I was simply reporting what users had posted about, the context of VS in 4Gb RAM seems to run slowly. This was a report about what happened with lots of RAM - and it was probably a gaming OPC to be able to fit that much.
BUT actually it is memory intensive. The amount varies with the type of memory tho.
For example, disregarding the OS and any pagefile+memory heap it needs, VS therunning programstill has most of it out in storage - as rendering needs parts (for the program, eg a filter or object; or the next clip) they are loaded. Every element (clips, music, voiceover etc) of a vsp has to be read from storage memory, and the higher the definition the larger the files are, and the more memory reads that are required. And conversely the processed output needs to be written somewhere too.

If all the vsp components are stored on an HDD, then read and write access times are relevant. If the files are defragmented on HDD then wait times are minimised, but every access has it in some measure. Add up the number of reads and/or writes done and the time involved is large.
If the PC has a lot of RAM, more of the program and vsp data can be loaded into fast access RAM, and the speedy result in processing time should be obvious. Nevertheless, every access to HDD storage for program or project data has a wait time.
If the PC has it's main store as an SSD, then any storage wait times are basically removed - all that's left is the time to change an address.

Metrics measuring cpu versus memory usage may well favour the cpu in terms of operations - it is after all jumping around in memory doing it's thing. But it takes a lot of cpu cycles to "match" the wait times that modern HDD have - read time average on the size of drives common in laptops is 6.5ms - time from issue of request to get 1st data back. How many cpu cycles could you pack into 6.5ms? Assuming nothing else caused a delay - rough maths indicate that a cpu running at 2ghz could execute 3.3million cycles in the time it waited for one response to an HDD disk read. In terms of events, no wonder a metric program that counts those shows activity favouring the cpu - but that doesn't mean the program is compute bound, but rather that faster memory would speed the entire process up.

Running VS off of a HDD doesn't feel the same as running it off of an SSD; not even close. It's laggy, and you can definitely feel the latency everywhere, because the NLE accesses disk assets on demand. Even switching to the "Templates" tab in the Library causes a massive loading delay if you are on a HDD, because it doesn't preload these things...

The NLE competes with the OS, Services, other applications, etc. for disk access. This completely kills the performance of platter drives. Platter drives work better for video editing when they are used for one thing - and one thing only (Exports, Caching, Media Storage, etc.). That way, nothing else is competing with the NLE for disk access, so you will always get best case scenario performance (for what you're doing) out of them. They are very bad as OS volumes, unless the machine is used for fairly rudimentary productivity or browsing functionality.

VS reads tons of small files off of the drive, all the time. NLEs are constantly caching things while you're editing, etc. If you have multiple video layers, then your NLE has to load both videos concurrently, which slows things down considerably because mechanical drives are only really good at sequential reads and writes. This is why Fragmentation kills their performance. An NLE is not a sequential-friendly application scenario, unless you only use one track with one video after another on it (this is like a music player playing a playlist). Once you get to multiple tracks, the HDD is at a huge disadvantage.

Every time something does a Read Request while you're Writing, it kills HDD performance, and the opposite is also true. Every time you have multiple assets that have to be loaded and played simultaneously (Video, Audio, Photos, Flash Animations, etc. on layered tracks), your will lose performance. It will be as if you're working with fragmented files on the disk volume, because this causes the drive to read files in a manner that is similar to how it reads fragmented files.

And while HDD bandwidth is fine for H.264, this really depends on how many tracks you use and the bitrate of the video files. If it's the boot volume, you also have to factor in load that may be placed on the volume by other applications... as well as the fact that you'll be both reading and writing to the drive while rendering; which will kill I/O performance because you are reading and writing concurrently - so media projects that play back "fine" in the NLE may have very bad rendering speeds once you "turn on" that performance bottleneck.

An SSD solves all of these issues. They also generate less heat and use less power. You don't have to deal with any of the horrible spin up when your machine has been idle, either.

240GB SSDs are too cheap to be stuck running your OS and Applications off of a HDD.

Put your OS and Applications on an SSD, then use mass storage for Media. An external HDD is fine. Just render to the system drive and put the media on the HDD (I'd personally use at least two external drives: One for Media Storage, and one for other stuff - Sound Library, Graphics, etc.); especially if you work with larger 4K video files.

[Davidk]

Yep, wot he said.
U need metrics, but understanding what they mean can be another thing.

[tletter]

U need metrics, but understanding what they mean can be another thing.

Agreed metrics are important but many do find metrics hard to understand and so they rely on suppositions and hearsay metrics of how "VS ran like a ferarri"

tletter
https://www.youtube.com/user/tletter

[asik1]

Is Ferrari a good metaphor for VS
https://www.youtube.com/watch?v=0vTc-kKEnUU

[Davidk]

That one certainly didn't