- Posts: 20
- Thank you received: 0
3 Post Moderation Rule for New Boarders (25 Jan 2021)
New boarders will have their posts moderated - Don't worry if you cannot see your post immediately.
Internal HDD vs External Thunderbolt (for best render speed?)
- raposanegra
-
Topic Author
- Offline
- Junior Member
-
Less
More
23 Aug 2014 12:46 #51680
by raposanegra
Hello,
I'm editing on FCPX installed on a SSD and my media files and projects are on my other internal HDD mounted on the Optibay. I noticed that the rendering times are slow... so I was wondering if it would be faster if I had the media and project files on an external thunderbolt drive?
Thank you!
I'm editing on FCPX installed on a SSD and my media files and projects are on my other internal HDD mounted on the Optibay. I noticed that the rendering times are slow... so I was wondering if it would be faster if I had the media and project files on an external thunderbolt drive?
Thank you!
Please Log in to join the conversation.
23 Aug 2014 20:15 #51684
by joema
Replied by joema on topic Internal HDD vs External Thunderbolt (for best render speed?)
Improving I/O performance will only help if that's the bottleneck. If you're mostly waiting on CPU, it won't help.
You can determine this by examining Activity Monitor or iStat Menus when rendering. Typically rendering is CPU bound, and usually all available cores will be pretty busy. Likewise I/O rates when rendering are usually well below the maximum disk bandwidth -- both in terms of bytes/sec and requests/sec. In such a case making the disk subsystem faster doesn't help.
Optibay is used in laptops, which typically have slower 5400 rpm drives. This makes it slightly more possible a faster disk could help, but I wouldn't bank on it.
Disk queue length is often informative, but the only way I know to monitor this is using iostat from terminal.
You can crudely approximate I/O size by running your task while watching Activity Monitor. In Activity Monitor select "Disk" and divide "Data read/sec" by "Reads in/sec". E.g, 100 megabytes/sec divided by 100 reads/sec = 1 megabyte I/O size. It fluctuates a lot -- you just want a rough number. Ditto for writes, but typically reads predominate so are more important.
You can also do the same for "data read" divided by "reads in", which is the total amount since last reboot. However unless you rebooted right before the test, you don't know how much of that cumulative activity was important.
You can determine this by examining Activity Monitor or iStat Menus when rendering. Typically rendering is CPU bound, and usually all available cores will be pretty busy. Likewise I/O rates when rendering are usually well below the maximum disk bandwidth -- both in terms of bytes/sec and requests/sec. In such a case making the disk subsystem faster doesn't help.
Optibay is used in laptops, which typically have slower 5400 rpm drives. This makes it slightly more possible a faster disk could help, but I wouldn't bank on it.
Disk queue length is often informative, but the only way I know to monitor this is using iostat from terminal.
You can crudely approximate I/O size by running your task while watching Activity Monitor. In Activity Monitor select "Disk" and divide "Data read/sec" by "Reads in/sec". E.g, 100 megabytes/sec divided by 100 reads/sec = 1 megabyte I/O size. It fluctuates a lot -- you just want a rough number. Ditto for writes, but typically reads predominate so are more important.
You can also do the same for "data read" divided by "reads in", which is the total amount since last reboot. However unless you rebooted right before the test, you don't know how much of that cumulative activity was important.
Please Log in to join the conversation.


