Storage Performance In Entertainment And Content Creation

Wow, great article. I think you've done an excellent job at showing with objective data how much of an improvement an SSD makes in all three articles. Up until these reviews there was little to show people other than just raw ATTO scores and other benchmarks. It's tough for someone to envision how an SSD can affect their overall system performance. With these articles you've given people real world examples from three different angles using measurable data to clearly see how an SSD is an improvement over HDD, especially as a boot drive.

Toms, you realize that if your "Quick Sync" benchmark is putting out a 700MB file and your "software CPU encoder" is putting out a 350MB file, then it invalidates the entire benchmark. The CPU bench is doing more actual work as it's compressing deeper then QS is. Small file size differences wouldn't be a big deal, but something as much as half, that means the compression / quality settings are not identical. Most likely QS isn't trying to compress it nearly as much as the software algorithm is.

Makes all your encoding bench's completely worthless until a method is figured to have the software CPU engine do the exact same workload as the QS engine.

a4mulaWow, great article. I think you've done an excellent job at showing with objective data how much of an improvement an SSD makes in all three articles. Up until these reviews there was little to show people other than just raw ATTO scores and other benchmarks. It's tough for someone to envision how an SSD can affect their overall system performance. With these articles you've given people real world examples from three different angles using measurable data to clearly see how an SSD is an improvement over HDD, especially as a boot drive.

How some queue depth,transfer size and seek distance bars can show me how better the ssd is? In the case of the encoding it is time ,but thats all. I realize ssd are faaaaaar better but such tables aren't helping.

Would be nice to have a this generation hard drive to compare to in one place. I see disk busy time isn't all that much compared to the total time in many cases.

Boot drives are great for an SSD as that is pretty much limited by disk reads and content creation can be limited somewhat by disk reads, but I do think hard drives in RAID provide good enough performance with substantially greater storage space.

Cool, that´s the thing I was looking for: recording in SSD with Fraps, tough it is a bit disappointed the transcoding time results (SSD vs HD).

Excellent Article!

While this is an interesting look I do think that media editing has a great many more things to consider than just HDD speed.
For one, due to your GPU selection you are not using the Mercury Playback Engine CUDA processing in Premiere, which will bottleneck the CPU during use, and skew the test results compared to an editing rig (in this case I believe it would tilt the results in the SSD's favor).
2nd, no serious editor is going to use a single HDD for video editing. At the very least you would have a content drive and a scratch disc (in addition to the system drive), and typically you would have a RAID0/1 for editing with. All of these setups are well within the budget of a single SSD, and will support much larger sizes.
3rd, Editing on a 240GB drive (much less using Adobe Premiere with only 8GB of Ram) would be a logistical nightmare for file storage. Yes, it does make the point that the SSD is faster (no contest there, and nobody would believe for a second that a HDD could beat an SSD in any performance metric), but comparing a 2TB drive (which has plenty of space), to a 240GB drive (which could only hold a few projects and files on it at once) is unfair price-wise. Yes, it may work for 5min youtube projects, but for wedding videos, or other longer projects (especially if there is a lot of raw footage) it would be impratical to use, and you would constantly have to be moving files, and deleting old projects to make space, which will waste much more time than the few minutes saved on export.

In general, buying a RAID setup (or having multiple raids for content and scratch discs) will provide much more space, and overwhelm even the fastest i7 processors on the market today, and still be cheaper than a decent sized SSD. Until CPUs and GPUs get faster there is no practical 'need' for having an SSD to serve up your content for video editing, unless you are on a server/workstation grade computer with duel Xeon processors. In short, if you have the money for a large enough SSD, you would see much more improvement in the system to invest in other parts. If you happen to have a top notch system already, then you could throw money at an SSD, but the test system used here would not qualify as being high end for video editing.

All that said, I would still invest in a 120 or 240GB SSD for a system drive. It is just for editing and data storage that it becomes impractical.

I have put alot of thought into this. I'm building my next PC withing the next 6 months for video editing. I will most likely have 2 SSDs for the OS running on raid 0 from the motherboard and have 8 2tb 5900rpm harddrives running on raid6 with an Areca card since most video is sequential. It can top 600-700MBps on sequential transfer.

ivyanevHow some queue depth,transfer size and seek distance bars can show me how better the ssd is? In the case of the encoding it is time ,but thats all. I realize ssd are faaaaaar better but such tables aren't helping.

On the contrary, these bars are very important as it shows just how far behind the drive is, and what types of loads the drive has to deal with. This is extremely important for choosing the correct drive for the job as different drives handle different workloads better than others. This is something I appreciate about Toms, they are not afraid of specifics, and go beyond things like simple rendering times and FPS scores to make an opinion. While I still disagree with the end opinion of the article (only on an issue of cost/performance), they have done an excellent job with the overall review.

CaedenVIn general, buying a RAID setup (or having multiple raids for content and scratch discs) will provide much more space, and overwhelm even the fastest i7 processors on the market today, and still be cheaper than a decent sized SSD.

Bingo, that's bang on. It is disappointing that they did not test a mechanical HD raid 0 setup which offers all the throughput needed while offering far more storage space (which is definitely a huge plus in media content creation) at the same or lower price.

CaedenV covers some good points there. I'm building a temporary PC for a friend atm for use with
After Effects. I don't have a spare SSD to use as a system disk, so it'll have a 450GB 15K SAS instead.
Likewise, the video storage will be 3 x 600GB 15K SAS (Seagate 15K.7) in hardware RAID0 using an
LSI SAS3442E-R PCIe card (if I didn't have the SAS disks to hand I'd build the system using a bunch
of 300GB 15K SCSI instead, using an LSI 20320IE). It will also have a typical 1TB SATA for general
storage and backup (Samsung F3).

So, the final graph showing the conversion times is interesting, but it's not realistic when it comes to
what any real professional would use for storing video. At the very least, it'd be RAID, and more likely
FC, SCSI, SAS or Enterprise SATA. I'd never recommend a consumer drive for doing pro work.

Thus, can you please try your test on a decent 15K SAS? Both single and several in hw RAID0? It
would be most interesting to see how it compares to the SSD.

Btw, I get a bit over 700MB/sec aswell, using 4 x 15K SAS, but I already know such an array is
still nowhere near as fast as an SSD for random I/O.

Ian.

Some of the comments (e.g. CaedenV, mapesdhs) clearly indicate what I think most of us realize; professionals tend to need very specific setups to maximize their productivity, and I'm going to sit here like a proper student and learn from their remarks.
For the "dabblers" among us, however, or those thinking about getting their feet wet, this article was very interesting.
Concerning palladin9479's remark, I think there are some good points there, but they are the sort to be explored in an article comparing QuickSync with alternate methods. The charts that they produce are still showing usage patterns which might be useful, not as a directly comparative benchmark between the methods, but to consider the storage subsystem best suited for each method.

jtt283Some of the comments (e.g. CaedenV, mapesdhs) clearly indicate what I think most of us realize; professionals tend to need very specific setups to maximize their productivity, and I'm going to sit here like a proper student and learn from their remarks.For the "dabblers" among us, however, or those thinking about getting their feet wet, this article was very interesting.Concerning palladin9479's remark, I think there are some good points there, but they are the sort to be explored in an article comparing QuickSync with alternate methods. The charts that they produce are still showing usage patterns which might be useful, not as a directly comparative benchmark between the methods, but to consider the storage subsystem best suited for each method.

lol, thanks for the complement. I would not say I am a huge authority on the subject (just an 'enthusiast dabbler'), but I did spend most of my college career fixing and optimizing machines for my fellow video majors and was really surprised at the time at what upgrades helped, and which ones didn't. In the end I found that it is all about a well balanced system, not about having 'the fastest' of any single part (unless you could afford the fastest of everything... which college students cannot).
I saw some people with P4EE chips that ran slower than P3 chips with a dedicated video rendering card (like the old RT2500 by Matrox). At the same time I saw systems with nice RAID0/1 setups, but very little ram, which cost them more performance than systems with tons of ram (at the time 2-4GB was 'more than you could ever need' lol, and people were duel booting XP and XP64bit to use the extra 1/2GB of RAM) paired with single drives.
Today I keep up with it and build the occasional system for friends and recently rebuilt my rig to do video editing for church and some non-profits I work with. If you are thinking of building a system do a lot of reading, and build around the specific software you plan on using because different ones use different technologies, and you don't want to throw money where it won't be effective, or overlook the advantages of a technology that could be in budget with minor changes to other parts. Adobe has a lot of good videos and articles on their site which can give you an idea of what kind of hardware to put behind their systems for various levels of awesomeness, but the main thing for video editing is the more parallelism in the hardware (multiple cores/processors, multiple HDDs/RAID arrays, more CUDA cores, more RAM, etc.) the better.

My own system is an i7 2600, 16GB of ram (need more but 8GB modules are too expensive lol), 3 single HDDs for system, scratch, and content drives (will move back to RAID when HDD/SSD prices drop more), and a nice fat GTX570 (completely overkill for what I do, but it fit the budget and enables CUDA processing for some of the filters/color correction I like to use, so I went for it). For what I do (mostly 2-3 layers of video, with color correction and simple transitions in glorious 1080p) it is largely overkill, but for those doing more intense work my rig would just be a starting place. My bottleneck is definitely in my storage system (the most I push my i7 is ~70% when editing), which will be releaved when I upgrade to 2TB drives in RAID1 and a 240+GB SSD system drive. My current 1TB drives (currently my content drive, and my scratch/render/storage drive) will become a RAID1 for data storage and rendering. That should balance everything again and get the most performance out of all my parts.
For someone just starting out I would suggest an i5, 16+GB of RAM, an SSD for the system drive, and then either a RAID1 for documents/rendering/content, or 2 seperate drives and have one as documents and rendering, and another for content. CUDA processing makes things nice (better quality and speed), but is limited to specific filters and usages, so I would not get it to start with, but would get it down the line if you can afford it. Onboard graphics are plenty until you get something to do CUDA. P67 or Z68 (or better as the Ivy bridge procs come out) chipsets are a must for the features they bring to the table, but the specific brand of board dosnt matter so long as it is stable, and follows the upgrade path you want to follow.
Good luck

I think this article didn't answer the most important question for the separate usage scenarios: What is the peak speed (top speed) needed to do this or that? I see some numbers on average speed, but these are just confusing and seems to be wrong.
For example, the blueray movie is said to have an average of 264.91 MB/sec.
When calculating the 43 min 58 sec with 12.12 GB that leads to an average rate of 4.59 MB/sec. And even if they wrongly means megabits/sec it is still around just 38 megabit/sec.

Anyway, for me dabbling with some DAW stuff, like using Cubase and reason running a with several different streams running software samplers triggering samples, multiple audiotracks and combining it with triggering videoclips (in Archaos) the harddrives aren't even near a bottleneck.
But I have it all running on separate drives (which is the key). 1 SSD for system/programs. 2 other drives for streams.

47340 said:

Some of the comments (e.g. CaedenV, mapesdhs) clearly indicate what I think most of us realize; professionals tend to need very specific setups to maximize their productivity, and I'm going to sit here like a proper student and learn from their remarks. For the "dabblers" among us, however, or those thinking about getting their feet wet, this article was very interesting. Concerning palladin9479's remark, I think there are some good points there, but they are the sort to be explored in an article comparing QuickSync with alternate methods. The charts that they produce are still showing usage patterns which might be useful, not as a directly comparative benchmark between the methods, but to consider the storage subsystem best suited for each method.

Ohh I'm not commenting on these charts, honestly QS using less or the CPU method using more won't make much difference. I was just pointing out that if their past "benchmarks" were producing those results, then those past bench's were invalid. I remember a few ones where they were praising how much faster the QS was and never mentioned the output file size, only the input file size.

Great comparison on the last page there ..... taking a upper echelon SSD and comparing it with one of the slowest hard drives available.

in_the_loopI think this article didn't answer the most important question for the separate usage scenarios: What is the peak speed (top speed) needed to do this or that? I see some numbers on average speed, but these are just confusing and seems to be wrong. For example, the blueray movie is said to have an average of 264.91 MB/sec. When calculating the 43 min 58 sec with 12.12 GB that leads to an average rate of 4.59 MB/sec. And even if they wrongly means megabits/sec it is still around just 38 megabit/sec.Anyway, for me dabbling with some DAW stuff, like using Cubase and reason running a with several different streams running software samplers triggering samples, multiple audiotracks and combining it with triggering videoclips (in Archaos) the harddrives aren't even near a bottleneck.But I have it all running on separate drives (which is the key). 1 SSD for system/programs. 2 other drives for streams.

Math is wrong. Disk busy time. Not elapsed time.

palladin9479Toms, you realize that if your "Quick Sync" benchmark is putting out a 700MB file and your "software CPU encoder" is putting out a 350MB file, then it invalidates the entire benchmark. The CPU bench is doing more actual work as it's compressing deeper then QS is. Small file size differences wouldn't be a big deal, but something as much as half, that means the compression / quality settings are not identical. Most likely QS isn't trying to compress it nearly as much as the software algorithm is.Makes all your encoding bench's completely worthless until a method is figured to have the software CPU engine do the exact same workload as the QS engine.

Your argument is if I transcode a higher bitrate, QD, transfer size, and seek distance will change? O_o? That's not how storage works.

JackNaylorPEGreat comparison on the last page there ..... taking a upper echelon SSD and comparing it with one of the slowest hard drives available.

Taking one of the most popular SSDs against one of the most popular hard drives. It's a very apt and simple comparison. If you're suggesting a Caviar Black, it's not like the single op transcoding job will be any different. Same on Caviar Green and Vertex 3 means same on Caviar Black. Hell a WD Raptor would be the same.

It would be interesting to see SSD vs HDD in compositing using image sequences...

407246 said:

Your argument is if I transcode a higher bitrate, QD, transfer size, and seek distance will change? O_o? That's not how storage works.

My argument has nothing to do with storage, I just pointed it out. If you would actually read it I'm referring to the workload differences between QS and "non QS" as a percentage. When doing benchmarks you try to set all variables equal except the one your testing. The workloads for the QS vs "non QS" were not equal, the "non QS" had a higher workload as demonstrated by the smaller file size. Given identical source input material, the output material of both QS and "non QS" should be identical, one merely takes longer then the other. They were not identical output material and thus the same algorithms were not used. Since media encoding / trans-coding is about quality vs size vs speed, different file outputs indicate one test used a deeper compression level to sacrifice speed for better size.

Now this article is about storage space, which is largely unaffected by the above differences. In previous Toms articles where "QS" vs "non QS" performance was evaluated the output file size wasn't mentioned. And if their getting a 50~100% discrepancy here, then they should of gotten the same discrepancy there. And thus the previous comparisons, especially how much "better" QS is, are invalid until further investigation.

179891 said:

My argument has nothing to do with storage, I just pointed it out. If you would actually read it I'm referring to the workload differences between QS and "non QS" as a percentage. When doing benchmarks you try to set all variables equal except the one your testing. The workloads for the QS vs "non QS" were not equal, the "non QS" had a higher workload as demonstrated by the smaller file size. Given identical source input material, the output material of both QS and "non QS" should be identical, one merely takes longer then the other. They were not identical output material and thus the same algorithms were not used. Since media encoding / trans-coding is about quality vs size vs speed, different file outputs indicate one test used a deeper compression level to sacrifice speed for better size. Now this article is about storage space, which is largely unaffected by the above differences. In previous Toms articles where "QS" vs "non QS" performance was evaluated the output file size wasn't mentioned. And if their getting a 50~100% discrepancy here, then they should of gotten the same discrepancy there. And thus the previous comparisons, especially how much "better" QS is, are invalid until further investigation.

Then you're talking about something else entirely. We already addressed concerns about quality in a separate article. For the purposes of this storage investigation, I think we can both agree that it's not a major issue.

In our previous articles, we set quality at a specific target and let the software do the work. And we did supply output samples that lets you do an apples to apples comparison for yourself. If you disagree without methodology, you're welcome to provide you're own findings. However, as a practical matter, users don't have the ability to fiddle with that level of minutia, which is why our comparison here and back then are still very valid.

In either event, if you're really that picky about video, you're still not going to rely QuickSync. Instead, you're going to turn to something like software encoder such as X264. We've repeated that point several times.

Cheers,
Andrew Ku
TomsHardware.com

407246 said:

Then you're talking about something else entirely. We already addressed concerns about quality in a separate article. For the purposes of this storage investigation, I think we can both agree that it's not a major issue. In our previous articles, we set quality at a specific target and let the software do the work. And we did supply output samples that lets you do an apples to apples comparison for yourself. If you disagree without methodology, you're welcome to provide you're own findings. However, as a practical matter, users don't have the ability to fiddle with that level of minutia, which is why our comparison here and back then are still very valid. In either event, if you're really that picky about video, you're still not going to rely QuickSync. Instead, you're going to turn to something like software encoder such as X264. We've repeated that point several times. Cheers, Andrew Ku TomsHardware.com

I was more commenting on how the differences should be investigated. What exactly is QS doing differently then the "non QS" codec. Is there a level of settings that can have a software codec outputting the exact same data as the built-in Intel QS. I have no doubt that the Intel QS is going to be faster, on die instructions tend to be. I'm wanting to know why you got a ~700MB file with QS and a ~350MB without. If it was something on the order of 10~20MB then it's no big deal, but that big a size discrepancy warrants investigation.

And again I have no issues with the bench's presented here as I highly doubt the above would make much different to a storage medium.

what about a head to head matchup with Hybrid drives in Raid 0?
two 320gb momentus XT hybrid raid o seems to be doable option at $300
and what about the pros (im an amateur user doing home movies,Fraps recording and transcoding
for the price of two 320gb hybrid in Raid would seem to offer the best price vs performance per gb
and what about the pros using SAS 15k drives in raid
this article while alot of hard work ignored any real life scenarios