Mike Watkins
Level 1
(90 points)
Q: Shared computer oddity
I am running Compressor 4.2.1 on my 2.26 Dual-Quad Mac Pro 4,1 with 64M RAM to work with files from FCPX 10.2.2 with Yosemite (10.10.5). I have a 2.53 GHz MacBook Pro that I have successfully set up as part of a shared computer set within Compressor. I've enabled 3 additional Compressor instances on the Mac Pro.
When I send things off to render, it seems like all is working well ... with one minor oddity. The Network Encoding Monitor (NEM) shows 4 instances firing up from Idle to Busy - presumably these are the 3 additional Compressor instances on the Mac Pro plus the single instance on the MacBook Pro. I initially see five subtasks running at once, and four of them are blazing through their work while the fifth loafs along.
As I keep watching the NEM as each subtask is completed, I will see an instance cycle down for a moment to Idle before popping right back to Busy as it grabs a new task off the "Waiting" pile. Eventually, as the available jobs remaining dwindle, one by one the instances switch back to Idle, until near the end ALL of the instances are Idle. But there's still that fifth subtask that doesn't show up on the NEM that is still churning away, seemingly in slow motion.
My theory is that the single "native" Compressor instance is not working at nearly the same speed as the shared computers (whether additional Mac Pro instances or the actual separate instance on the MacBook Pro). Sort of corroborating this theory: whenever I "Send To Compressor" straight from FCPX (meaning I can only compress on "This Computer"), it takes significantly longer (5x) to do the same job with the same settings.
Anybody seen anything quite like this? Thanks in advance if you have any thoughts you might share.
Mike
Mike Watkins
Level 1
(90 points)
Hey BenB - I'm glad you posted. I did finally noodle what was going on, but forgot to post here. As embarrassing as my misunderstanding was, I should have posted here in the interest of making a more complete knowledgebase.
To answer your question first: my problem was that one of the Compressor instances always seemed to be running way slower than the rest. The 90-second master file that I was testing with would get split up into nine 10-second chunks and an audio portion (as expected). Eight of the nine would take 53 seconds on average to process, but the ninth always took much longer (130+ seconds).
In my OP, I mentioned that my shared computer set was a Mac Pro with 3 additionally-enabled instances (beyond the base instance) as well as a single instance on a networked MacBook Pro. When I opened the Network Encoding Monitor (NEM) on the Mac Pro, I mistakenly thought the four entries represented the 3 additional Compressor instances on the Mac Pro and the single instance on the MacBook Pro. So when I saw the four instances showing Idle as I waited for the final slowpoke to finish, I assumed that the job belonged to the initial ("non-additional") Mac Pro instance that was running slow.
Took me a while to think that the MacBook Pro might have its own NEM, so I fired it up and tried the render again. The slowpoke instance was indeed the one on my MacBook Pro. Initially, I was surprised - I figured the 2.53 GHz processor in the MacBook Pro would be able to at least be in the ballpark of the slower 2.26 GHz processors in the Mac Pro. But the Mac Pro outranks the MacBook Pro in almost every other applicable metric - processor microarchitecture, RAM, GPU speed, VRAM. I'm sure Compressor is leveraging a lot of this for the Mac Pro instances, and the MacBook Pro can't keep up.
Obvious solution: stop using the MacBook Pro ... it's hurting, not helping!
