Frantic Software is pleased to announce the release of Deadline 2.0 (build 2.0.18035). Some key new features include:
The new Power Management feature can reduce energy consumption by automatically turning machines on and off based on the current farm load.
The new Deadline Pulse application can be used to improve Deadline's performance by improving Monitor refresh rates, and decreasing Slave polling time when searching for a job.
Monitor submission dialogs are now written in vbscript, and can be added and customized as necessary. See Deadline Scripting for more information.
The pool limit has been increased far beyond the previous 36 pool limit.
I have a question about Pulse. Can you explain more in detail what it does? I am really curious.
From what I get, if pulse is running, the slave won’t query the repository unless pulse tell them to do it. is that it?
I was wondering if you have implemented in pulse the sugestion I made some time ago, where a more powerfull machine would always get frames to render before the slower machine.
Actually, if Pulse is running, the Slave will not have to query the repository at all. Pulse will have the latest status of the repository and will tell the Slave what jobs ara available.
In pre-2.0 days or when the Pulse in 2.0 is down, every slave has to poll data from all the job folders in the repository to find possible jobs which means heavy network traffic.
With Pulse, only the Pulse server reads through the repository and caches data which is then made readily available to all the Slaves. This is why it is suggested to run Pulse on the same machine as the Repository, as this avoids network traffic between Pulse and Repository.
I am sure Ryan can shed some more light onto the subject…
With Pulse running, you can set your monitor auto-update time to ridiculously low settings (the minimum is 10 seconds). As a result, the Monitor will refresh in near real time - with several hundred jobs on the queue, it usually takes less than a second to refresh. No more continuous Refresh Jobs button pressing…
We are working on a mini-monitor application in conjunction with Pulse where you can drop your important jobs and watch their progress in realtime in a small floater without the need to open the whole Monitor window.
No. (Our IT dept. insist that the word “swarming” does not describe the way Deadline works, it should be “pulling”, which involves lots of “polling”).
The good thing about the approach is that it is VERY stable as there is no weakest link (Manager) that could bring it down, but a bunch of smart slaves that pick their jobs themselves.
The not so good thing about that approach was that when you add more slaves, there are more machines polling the repository for jobs. Funnily enough, the less machines were rendering, the slower the network was becoming. This might not be an issue with 10 slaves, but we are currently running over 200 machines, and some customers might have more.
In addition, to reduce this overhead of machines looking for jobs, there were artificial delays in the polling which made the picking of jobs slower - it could take minutes until all slaves “knew” a new job was there…
Then along came Pulse and turned “Deadline” into “Liveline” It caches the repository and elliminates the file access to the repository. Instead of 200 slaves reading files from the repository, only the Pulse does so (and locally, if installed on the same server as the repository). The Slaves connect to Pulse instead, ask for a job and get it. If Pulse is down, they revert to the old method, so rendering never stops
It caches the repository and elliminates the file access to the repository. Instead of 200 slaves reading files from the repository, only the Pulse does so (and locally, if installed on the same server as the repository). The Slaves connect to Pulse instead, ask for a job and get it. If Pulse is down, they revert to the old method, so rendering never stops