Hello
We’re getting a recurring issue with our Mac render nodes. If the slave’s display is off (no other energy saving features enabled), then it takes forever for the machine to release the task once it’s complete. Giving the machine a nudge by logging in – either physically or Remote Desktop – will invariably release the completed task and move straight on to the next one.
Is this a known issue? For various reasons, we don’t want to keep the displays on 24/7.
Many thanks
Tom
Hi,
I think you are hitting the OSX App Nap issue, which affects all applications under OSX Mavericks. Here’s our documentation referring to this annoying issue and some possible work-arounds, which should solve the issue (Try enabling the checkbox: “Prevent App Nap” on all your troublesome machines for slave, pulse):
thinkboxsoftware.com/deadlin … rkstations
Let us know how it goes!
Mike
Thanks Mike.
That definitely helped, but I can still see that a Mac with a sleeping display will take longer to release tasks than an identically specced one one with the display on. Weird, right?
On another note, installing Deadline on a headless Mac takes much longer than one with a display connected – and quite often needs a prod through Remote Desktop to complete the install. Do you think this could be related?
Many thanks
Tom
Right, nearly there. Sounds like a few more ‘apps’ in OSX need to be told to not go to sleep here as well, which are having a knock on effect and causing Deadline to ‘slow down’. I know we worked through these issues but I didn’t deal directly with the issue. I assume if you stop the monitor from switching off, all is still well? Let me give a poke to a couple of colleagues to look at this thread later today (different time zones) 
Yes, that’s correct. Thanks Mike: I’ll stay tuned.
Hey folks, So I was one of the people who directly fought with this problem.
There’s actually no direct way to prevent this entirely except for stopping the display or the screensaver from coming on (Didn’t check if setting the brightness to ‘off’ affects things). A Mac without a display attached doesn’t hit this problem.
The installer via remote desktop / VNC does hang up a bit, which is unreleated and seems to be the fault of the progress bar. To work around that problem, eclipse the installer with another Window.
Now, back to App Nap. The issue with this is that to actually prevent calls to the operating systems sleep() call from taking longer than expected, programmers actually have to implement calls to the kernel to request it from stopping. From a bug we found in 6.1, it looks like the more calls to sleep() an application makes, the longer the operating system will hold it off. We changed out code to call sleep() as little as possible and that prevented a lock up in Deadline after a task is completed where it spun for however long it needed to wait for the next task scan (which sounds identical to what you’re describing). We’ll need to check that fix made it into 7.0’s code base.
I should also mention that when we were testing, a Maya scene that took 17 seconds to render without the screen on took 15 MINUTES with the display off. Autodesk may have fixed this however.