I show results from my latest SSD purchase.
  • For those that don’t know I built my own computer about 5 months ago, back then I didn’t do a raid array, but I found a 1TB SSD that could possibly take it’s place.
  • So I crawled under my desk and shut down my computer and put in this 960GB (almost 1TB) SSD drive for only $599

Royalty free music by PremiumBeat.com

Products Used In This Video – Find Prices

Help me make more of these types of videos by purchasing gear from the links posted on my site. It costs you nothing extra, and helps support me to make more videos.

5D Mark3
5D Mark III


  • I think your bottle neck stills the drive speed. Even you’re using a single SSD of 960GB, a SSD raid0 is way more faster: you can reach something around 800~900MB/s. For example, a 2x256GB SSDs raid0 is faster than a single 960GB SSD. Search for some videos on youtube for SSDs array, you’ll the amazing speed that 2 SSDs can reach. Maybe this is enough to stop the dropping frames…

  • @Rodrigo thanks for the suggestion. But the highest stream off the hard drive I saw was 46MB/s which is way lower than the 490MB/s the SSD drive can do, is the monitoring tool I am using not showing the peaks but just the average stream off the hard drive?

  • The 490MB/s, is the, let me say, “general” speed. In some cases, according to the size or format of file you’ll reach a different speed. Another thing you should enable to your SSD is the TRIM (search on google to do that).

  • I’m not sure where the issue is, but I wonder what your results would be if you have 6 videos playing, but have them all be the same video. In this case, it’s not reading 6 different files but one file. The GPU would still have to process this because the playback would be in different areas, so this may shed some light on whether it’s a disk or processing issue. Just a thought.

  • Nice info in this video.
    Sometimes your bus capacity can affect speed. So the bottleneck can be in the cable and data management.
    But as you keep mentioning, codec are usually a huge stumbling block. Blame AVC. It’s an efficient codec but was never designed for editing. Where’s my 220 mb/s ProRes fly into and through my NLE, my 24 mb/s AVCHD (MTS) coming out of my little Canon Vixia, Contour POV cam, and Nikon D600 totally slams the system. My NLE CAN edit it but doesn’t like to. Far better to transcode into your NLE’s native file format because the few minutes you save trying to edit right away is paid for in the agony and balking of the system during edit. That’s a part of my workflow and it gives me a few minutes time to get coffee.

  • Hi, Dave:

    I know it doesn’t matter at this point, but it will in a few months. I have a B.S. in CIS; get your PC off the floor! Even with it slightly raised, carpet is a PC killer. First, all of the fans that you’re using sucks in dust and dust particles. These particles will collect and create an adhesive for more dust. If you have animals, this amplifies it. Even if you vacuum, it doesn’t solve it.

    This is bad for two reasons: 1.) The dryer the component, the hotter it runs. Sure, you’re liquid cooling, but the external radiator and hoses, along with all of the internal wiring and motherboard, they’re meant to stay dry, but the hotter they become, the more they will crack over time. Your liquid cooler has internal friction, when mixing that with hoses that have cracks due to higher heats, well, liquid finds the first and nearest source. All of that electricity and water, well, you get the idea.

    The second reason having a PC on the floor is a bad idea, static electricity. The dryer the environment, the more static is potential to build. Static electricity uses dust as it’s source of connection, which creates an arc to its nearest source, anything that can ground.

    I don’t mean to alarm you, and it’s none of my business. I just figured, with all that you do for the community, I would like to offer technical advice that could save you in the long run.


    Outside of that, nice speeds. 😛

  • The 490MB/s is a peak performance value. It assumes all the data is stored sequentially on the disk. In reality, performance on the M500 960GB can fall to 77MB/s under heavy load. In the case of the 6 DSLR videos, that’d be a lot of data to transfer as well as a lot of hopping around on the disk to each of 6 data locations.

    Anandtech has an excellent review of the M500 which shows real world performance. The entire review is good, but I think this particular part of the article is most relevant: http://www.anandtech.com/show/6884/crucial-micron-m500-review-960gb-480gb-240gb-120gb/7

    Specifically the second graph titled, “Heavy Workload 2011 – Average Read Speed”.

    I know your benchmark only showed 46MB/s, which still should be under the 77MB/s so there’s still some question as to why this is happening.

    It’s possible that the benchmark numbers are inaccurate. It’s also possible that between all your drives you’re saturating your SATA bus.

    I didn’t notice in the video, but is your RAM getting maxed out causing any swapping?

  • as far as Gopro footage goes, are you using the Cineform software? I use that convert it and then import, editing is way easier in CS 6 that way.

  • @Patrick I have the software but I wanted to try the footage straight from the camera first.

    @Ron that is a good idea I will test for that.

    @Legion thanks for the great info. No the RAM (32GB) never got saturated.

    @Tim Not sure if you noticed but is was sitting on top of a blue piece of 3Form material.

    @Rodrigo I just checked and is was enabled using the “fsutil behavior query disabledeletenotify” command.

  • Dave, Ive built a similar pc to yours and i’m having the same issues with Vegas and Adobe, especially when I add certain animated Text layers. I tried having ALL my media and project data on one ssd, and tried having my source media on a mechanical 7200rpm drive, but still get similar issues.

  • @Ron I just ran that test where instead of 6 different streams I used only one stream 6 times and it did not drop frames. The CPU usage was much lower and also the disk transfer rate was also much lower. The GPU load for the diff streams was 15% and for the same streams was 5%.

  • the problem would have to be Premiere itself. I didn’t design the program, but your computer should be able to do all of no problem. It is probably just the program and windows trying to communicate. I wonder how premiere communicates with mac os VS windows os Great question by the way.

  • OK I took the 6 clips and transcoded them to DNxHD highest quality and they didn’t drop any frames in that same test.

    The CPU worked just as hard as the other test but only used 10 out of the 12 threads. (the dslr h.264 footage used all 12 threads)
    The GPU worked at the same level as before
    The amount of data transferred off the SSD was much higher if not double, peaking at 100MB/s.

    So if I were to reach the right conclusion the SSD is not the issue because it could stream 100MB/s peaks no problem without dropping frames (earlier test it peaked at 43MB/s). The GPU does not seem to be a factor here because it was under the same load as in the earlier test. So that leaves the CPU, just because it is not peaking all threads at 100% doesn’t mean it can handle decoding all 6 streams at the same time. Perhaps it is a mutli-threading issue.

  • I think it is, in fact, the SSD. I don’t have a BS in CIS and am not a storage expert, but here is my thought: If 6 different video files caused missed frames but 6 versions of the same video did not, I would argue that the disk cannot read the data from 6 different areas of the disk fast enough. I’ve never seen where a disk drive was waiting for a CPU or GPU. Storage is nearly always the bottleneck in any system when considering CPU, GPU, RAM, and disks. Again I’m no expert, and I welcome ideas to the contrary.

  • I love this discussion. You should make more videos on computer gear, and specifically the storage part. I want to know what the best hard drive set up is, so you can get rid if this BOTTLE NECK.

  • If you think the CPU is the bottleneck then what could be happening is the renderer is having to wait for a particular thread to finish.

    So in this case you have 6 videos. Each clip could be rendered by a separate thread and when they’re done they’re composited together for the final frame. If one of the threads takes longer than the others to complete, the compositing thread will have to wait for it, even though the others are done, causing a dropped frame.

    That said, I don’t know what kind of multithreading strategy Adobe has used, so this is all conjecture.

  • To get increased SSD read & write speeds – the SSD compresses and decompresses each file.

    Already compressed video footage cannot be compressed further – reducing the SSD rates significantly for single files (ie down to the underlying ‘real’ IO rates)

    The SSD also has a limited set of resources to decompress its files – so reading (ie decompressing) multiple (incompressible) video files may lower your SSD read rates further (if the SSD decompressor is maxed out).

    RED Raw is incompressible (but the SSD will still attempt to compress it)
    DNnHD can be compressed (and may be easier to decompress with this specific SSDs algorithm)
    Other Codecs may present different types of torture tests.

    A quick way to see if you are hitting and SSD issue would be to read / write half of the footage to the SSD, and the other to one of your other (very cleanly!) labeled hard drives using PP CS6.

    If my guess is correct – you may find that use of 5 average speed HDD (eg LaCie Big 5 with Thunderbolt) will give you an order of magnitude more Real I/O, giving your CPU and GPU the workout they deserve.


    Love your videos btw.

  • I thought of another test that may help determine if the bottleneck is SSD or processing — Create a Ramdisk. (A Ramdisk is using a portion of your RAM like a drive but it’s much faster than a disk.) If you can fit the 6 video files into 4 GB of RAM or less, you can use DataRam’s free Ramdisk application and copy those 6 video files into a RamDisk. When playing back those same 6 video files from the Ramdisk, if they hiccup, then your issue would not be the SSD, but processing. If there is no hiccup, then the issue should be SSD.
    To verify that the Ramdisk is much faster than the SSD, run your same Crystal DiskMark speed test on the Ramdisk and let us know what you get.

  • I happen to have a BS and MS in Computer Science, but don’t pretend that that helps much to fully understand what’s going on in this situation.

    My guess is that it is the SSD. The six simultaneous streams are a pretty challenging problem for the SSD. When I’ve seen similar problems (nothing seems to be the bottleneck) when performance profiling my own code, the culprit was usually seek time. A RAID with striping or mirroring (0, 1, 10, but not 5 or 6 for other reasons) could help.

    Your comment on multi-threading is interesting as I have seen many cases of threads waiting for one-another that presented similar symptoms.

    Related to the GoPro codec’s demands on the CPU: My work-flow always involves breaking video out into individual images (PNGs since they are losslessly encoded). This avoids a lot of issues with codecs and performance. Then again, I’m working in a very different environment: Mostly pure 3D imagery, sometimes incorporating video, using Blender, under Linux.

  • This is how I believe it goes:
    6 videos playing from same source, around 45000kbps each times six…
    Your SSD is only reading around 500mb/s on some certain data… sometime it read some data x10 times slower, depending on what kind of data it reads… Using the same source, would be no problems. For best perfomance, spread out the media on a own disc.. But that would be to much work and too complicated for daily use. Sometimes there are no easy/cheap solutions. This will be a brainer for atleast 5 more years…

  • I was thinking (since I’m having similar ssd issue) about using a pci card to attach my ssd – not using the sata bus? Wonder if that’s do-able? or a waste of time?

  • Well, you can buy a pci express SSD instead of an SATA SSD. They cost a little more, but that is possible.

  • I haven’t seen any evidence that the IO speed of SATA is being pushed.

    With music systems you sometimes see 1000W pmpo (but 1W RMS printed in small writing).

    The Intel Atom beats the ARM on power efficiency (small print should include ‘only when the Intel compiler is used to optimise the benchmark to avoid running the. test’)

    This SSD claims a maximum IO speed of 490MB a second (what is missing is the worst case rate when several steams on incompressible information is being read concurrently).

    If you do get a new SSD – make sure you note the minimum speed – or look for the IO rate when compression / decompression is switched off.


  • We’re about to buy a new computer + 25GB worth of RAID (not including backup) and this thread has given me pause. Given all of the above intrigue, I wonder if anyone has evolving opinions re: the SSD, RAID, startup disk, etc. for a brand new computer? Does anyone have an opinion as to what would the fastest, safest set-up be for a very large Pro Res HD file project with lots of glow filters and color correction? Thanks for any feedback in advance:)

  • I believe it is an inefficient implementation of the decoder.
    AVCHD although gives great quality for the size is a poor format for editing. It taxes so much the whole system and even adobe has not found a way around that. Of course CPU and hard drive speed will matter (pci-e ssds are the best..), but you shouldn’t be building a system to optimize a poor codec. It is better suited for hardware benchmarking…
    The best solution is to transcode AVCHD to a more editing friendly format. I know it will take a little bit of time but it will save you much of the dropped-frames-frustration. It will also save you the time from coping the data around if you have a very fast hard drive with a limited space.
    In general for the hard drives this is a good reference:

Signup for Dave’s Newsletter (not working)

  • bandh.jpg