Sign in with
Sign up | Sign in
Your question
Closed

Storage Performance In Entertainment And Content Creation

Last response: in Reviews comments
Share
January 13, 2012 4:48:44 AM

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.
Score
1
January 13, 2012 6:25:41 AM

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.
Score
4
Related resources
January 13, 2012 6:36:55 AM

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.
Score
1
January 13, 2012 10:04:39 AM

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.
Score
1
a b G Storage
January 13, 2012 11:55:01 AM

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).
Score
0
a c 289 G Storage
January 13, 2012 12:03:39 PM

Excellent Article!
Score
0
a b G Storage
January 13, 2012 12:13:41 PM

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.
Score
7
Anonymous
a b G Storage
January 13, 2012 12:16:58 PM

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.
Score
2
a b G Storage
January 13, 2012 12:23:05 PM

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.
Score
2
January 13, 2012 12:36:26 PM

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.
Score
3
January 13, 2012 12:41:16 PM


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.

Score
3
a b G Storage
January 13, 2012 1:21:56 PM

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.
Score
0
a b G Storage
January 13, 2012 5:20:44 PM

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
Score
2
January 13, 2012 6:11:52 PM

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.
Score
0
January 13, 2012 9:12:51 PM

Onus 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.
Score
0
a c 115 G Storage
January 14, 2012 12:32:40 PM

Great comparison on the last page there ..... taking a upper echelon SSD and comparing it with one of the slowest hard drives available.
Score
0
January 14, 2012 2:22:38 PM

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.
Score
0
January 14, 2012 2:23:44 PM

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.
Score
0
January 14, 2012 2:25:20 PM

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.
Score
0
Anonymous
a b G Storage
January 14, 2012 3:29:44 PM

It would be interesting to see SSD vs HDD in compositing using image sequences...
Score
0
January 15, 2012 11:41:57 PM

acku 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.
Score
1
January 15, 2012 11:55:38 PM

palladin9479 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
Score
0
January 16, 2012 12:51:38 AM

acku 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.
Score
0
January 16, 2012 2:55:36 AM

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
Score
0
January 16, 2012 12:34:36 PM


caedenv writes:
> 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

Spot on, and at least for uncompressed video the old saying was it's all
about how much one can process, not how fast. Especially true for 2K,
4K and 8K film. Years ago it wasn't possible to get reliable high-speed
I/O on PCs, but that's changed, though consumer builds do of course lack
ECC protection which is a concern for pro users. Multi-socket XEON systems
tend to have this anyway so it's not a problem, but they're costly and
generally can't be overclocked. It's something I'm looking into atm, eg.
oc'd 990X or SB-E vs. dual-socket i7 XEON (main advantage of XEON systems
is the much higher RAM capacity - my Dell can take well over 100GB).


> 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

Top-end systems are often turnkey solutions supply ready to go, optimised
for the application, not really general purpose at all. Discreet systems
are like this.


> 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

I have a range of systems, couple of Avid SGIs (O2, Octane2) and several
original Discreet systems (quad-1GHz Tezro with Flame/Smoke and aual-600
Octane2 with Flame, each with 24 x 146GB 15K SCSI; O2 Effect with 22 x
73GB 10K FC) all with HD/SD digvid options, breakout boxes, etc., a
couple of SGI for hardware-capture/playback (customised O2, Octane2 V12
with Cosmo2 board, both for reilable JPEG) and some other high-end
systems aswell (quad-500MHz Onyx2 IR4, 36-CPU Onyx3800 IR4, HD digvid,
72GB RAM, not really setup yet though). I have some Adobe Premiere
systems but don't really use them.

PC-wise I have several systems, some for benchmarking research: i7 875K
(overclock not yet sorted out), dual-XEON X5570 Dell T7500 with Quadro FX
5500 (might switch to a Quado 600 I've just obtained if it's better), an
Asrock X58 Extreme6 with another X5570 (should oc like crazy), and a 990X
not yet set up. A mix of FC, SCSI, SAS and SATA storage. All the other
systems are more for 3D/CPU benchmarking (two i7 870s, i3 550, i5 760
[though this will be away on loan for a while], i5 760, and a range of
AMD builds, mix of mbds, range of GPUs).

Combining SGI/PC hw in an optimised manner is my current focus, but I'm
also doing a lot of PC benchmarking.


> 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

I did test an SSD with Flame, no observable benefit for colour correction,
but the bottlenecks on a PC platform could be very different. Hard to say.

What you could do is run Process Explorer to see what I/O is occuring
while running your app.

Ian.

Score
0
January 16, 2012 1:26:31 PM

palladin9479I 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.


Oh! Well, I believe for this specific story, I might have used a different bitrate setting for the QS encoding path. Honestly, I can't recall. The testing for this story was done back in November I believe, and we're kind of swamped trying to catchup with everything post-CES.
Score
0
January 17, 2012 2:05:20 PM

What about simultaneously recording and playing back 64 tracks of .wav files? Would like to see how it reacts in a big multi tracking environment .
Score
0
February 7, 2012 9:36:17 AM


Thought some here might find the following interesting:

http://www.sgidepot.co.uk/misc/LSI_SAS_3442E-R_3x_Seaga...

That's for 3 x Seagate 600GB 15K SAS, hw RAID on an LSI SAS3442E-R PCIe card (the array
just has 3 disk becasuse the 4th is being used for general data & backup in the system I built). The
3 disks cost me 225 UKP total, the SAS card cost 32 UKP.

This is just on a simple P55 system (Asrock P55 Deluxe) with an i5 760 @ 4GHz (loaned it to a
friend for use with After Effects).

Other data available on my site here:

http://www.sgidepot.co.uk/diskdata.html


Ian.

Score
0
August 12, 2012 2:36:53 PM

Umm, the fraps benchmark calls for 300+ MB/sec. Nope. That doesn't remotely pass a sanity check -- you ran this on a spinning drive that couldn't sustain that rate.

The actual data rate using your data panel numbers was 23 GB over 27 mins = about 14 MB/sec.
Score
0
!