Does deadline work with 64bit?

#1

well the title says it all, does deadline work with 64bit Lightwave and XP64?

Frantic Films doesn’t seem to have a contact email address :rolleyes:…which I guess doesn’t bode well for support but I wanted to try out Deadline anyway.

#2

Yes, but I don’t know why you should bother! I recently tested a bunch of renderfarm controllers and Deadline fell down to the end of my preferences!

Anyway, you can download a demo version of Frantic’s site and test it for yourself on your setup.

#3

ah…ok…hmm.

well I was going to try it because it’s free for only two slaves but offers more application support than Amletto which is also free. Is there a particular reason why you didn’t like it?

#4

I tested with a very simple scene, something that would take a couple seconds per frame, only a bunch of them to make (250 frames, I think).

In pure straight Lightwave it was taking 11:51 (11 minutes, 51 seconds)

Render controllers usually do a bit of sitting around, waiting for nodes, organising statistics, sending frames here and there, etc so it’s not strange that it takes more time. So:

  • Lightnet, the free render controller, did the same scene in 24:57
  • Tequila Scream did it in 26:something
  • Butterfly Netrender 28:something
  • Smedge 13:44 (woohoo!) :beer:
  • Royal Render does things in a very different way and uses all possible threads using settings I didn’t even know where to start to look, and this particular scene did it faster than Straight LW, don’t understand how… Took around 9 minutes
  • Deadline took… (brace yourself!) 1:04:48 (yes, one HOUR!).

I did more tests, of course, for example:
-Straight LW - around 12 minutes
-LightNet - around 14 min
-Smedge - around 13 min
-BNR around 19 min
-Royal Render - around 18 min
-Deadline - around 30 min

It may be because, as you say, it’s free for only 2 machines (I only used one computer for tests because some controllers only alowed one engine to be used in the demo and wanted the tests to be consistent), but I guess the benefits of such will come when using hundreds of nodes in big companies… Maybe it doesn’t matter then!

But for me, it matters a lot! :argh:

#5

We use Deadline here at work on a fairly small farm (25 boxes) and it is very, very good. We don’t use it with Lightwave though. It works incredibly well with Max, Maya, After Effects and Fusion though. Perhaps you didn’t have it set up correctly? The jobs submitted from Maya appear instantly in the Deadline Manager and render straight away. From then on it has nothing to do with Deadline, it’s the box rendering the frame!

#6

I think I set it up correctly, otherwise it wouldn’t work! I had to figure out my way over 6-10 renderfarm controllers, every one with different setup methologies and difficulties, and if there is anything in favour of Deadline is it’s easyness of configuration! Very easy in comparison with others!

Since you said that, I gave it another try, just in case… I picked a scene I had jsut rendered and took 47 minutes. In Deadline, using the same computer, it took 1 hour and 12 minutes.

Analysing the statistics (another good feature of Deadline, wich has some interesting stats (and I love Stats!)) I cound see that there is a gap between 6 to 10 seconds between each frame (Frame N rendering time versus Frame N Finishing time - Frame N-1 finishing time). This alone is a no-no for me… I mean, if we are talking about frames that take 30 minutes to render, that’s completelly irrelevant, right?! Because 10 more seconds per frame is nothing next to 30 minutes! But my scnes are usually very quick ones… becasue there are a lot of passes nad I render very few things in each… So I am talking of scenes that take between a few seconds to 3 minutes, tops… so 10 more seconds in each frame is actually a LOT! For example, this project I am working on will have, at least, more than 20K frames (yes, 20 thousand frames!) This would mean 10x20000=200000 seconds more, or 55 hours more!!! For no reason!

I was still not very happy with it as I could see that it was only sending one frame at a time. As I have 2 cores, usually I send 2 frames at the same time in every other renderfarm controler, opening 2 instances of LWSN (the rendering engine). In Deadline it was not a transparent thing to do and I could see that iw was using the 2 cores (2 threads) but only one frame at a time. We KNOW that having 2 processors working on a frame is NOT the same thing as having 2 processors with one frame each, it’s a bit slower… So I checked all the options and managed to open 2 LWSN like the others… No luck, still took more than 1 hour (1 hour and 2 min, to be more exact). Better, but still not enough for me, as I can finish the same scene in 47 minutes using other controller.

As the time per frame in LWSN itself is also higher, I wondered what the heck was causing this… Well, I could see that the Deadline Slave process itself is taking about 2-8% of CPU… This will, of course, cause an increase between 2 to 8% of rendering time, as the other rendering controllers (the slave part) are not takin even 1%, they are usually at 0 steady… just quickly sending comendas or whatever they do.

Deadline Slave process can be doing a lot of stuff I have no idea about, but I couldn’t care less, as the results are not satisfying my needs… the need for speed :slight_smile:

I’m not saying Deadline is not good, it is, as it has a very nice interface, it’s easy to setup and easy to send and manage scenes between different platforms, average statistics etc… but is the slowest around and for that reason I wouldn’t use it unless it was the last rendercontroller around.

#7

Interesting tests. I was also wondering whether you had looked at the task size setting - if it’s set to 1, it’ll be loading the scene again after every frame has completed which could be part of the cause. If you have it set to something higher (I guess if you’re only using one machine the task size could be set to the total number of frames) you should lose the scene loading time which might help.

#8

That’s a common thing in Lightwave screamernet, and Deadline uses that option as well, just by checking the “Use Screamernet Rendering”.

From the manual:

“Use ScreamerNet Rendering: ScreamerNet rendering keeps the Lightwave scene loaded in memory between frames, which reduces overhead time when rendering. This has been tested with Lightwave 8.x and 9.x.”

So yes, I was using that as well.

#9 
 I have a hunch what the reason might be.
 As you might know, Deadline does not use a Manager. The slave application is responsible for looking for and picking up the next matching task from the Repository. Now keep in mind Deadline was developed and is being used in a company with around 200 machines on the farm, and each of these machines has to poll the repository for jobs when it finishes the previous task. On the bright side, this means as long as the file server has the repository visible to all machines on the network (read: the hardware is ok ;)), the system will continue rendering, even if 99% of the slaves would die an unexpected death for some curious reason like alien invasion or something. In fact, Deadline has been running continuously at Frantic since 2004, 24/7 with the only downtime caused by hardware failures.

On the dark side though, polling for jobs when hundred of machines jump onto a job at the same time can hit the network significantly.
 
 Thus, Deadline has some settings to delay the polling for the next task and for the next job. A single machine with lots of second-long tasks is the worst case scenario for it - it was designed primarily to run hundreds of slaves with 30 minutes up to 24 hours per frame (on Superman Returns we had frames taking several days), so the delay has never been very obvious in our practice. 
 
 As all other settings in Deadline, you should be able to tweak the polling timeout between tasks. The default wait between tasks is 5 seconds, for 250 frames this would mean about 21 MINUTES of pure waiting. If you are running less than 20 machines, you can set this delay to 1. 
 To do so, set the Monitor to Super User mode, go to Tools>Configure Repository Options and scroll down to "Slave Delays" > "Delay Between Tasks".

As mentioned already in this thread, submitting with a Task Size > 1 will combine multiple frames into a single task. Setting the Task Size to 250 or higher for 250 frames will render all 250 frames in a single task on one machine without any waiting between frames. We use this approach when creating QuickTimes using Fusion for example (since movie files cannot be writtent to by multiple machines). The drawback of this approach is that if the task would fail for some reason, it would have to start from the first frame again. If the job is simple and stable, it is probably not an issue. When rendering at the edge of memory limits with heavy scenes, it is a good idea to keep the Task Size small to avoid wasting time rerendering frames.

Please note that our support forum moved last week to a new URL:
http://support.franticvfx.com
A question like this could have easily been answered there by the developers…

 Btw, the claim that there is no contact / support email for Deadline is of course groundless:
 [http://www.franticfilms.com/software/products/deadline/contact/](http://www.franticfilms.com/software/products/deadline/contact/)
#10

ah…y’see…I made the mistake of clicking the contact button: http://www.franticfilms.com/software/contact/

:rolleyes:

#11

Thank you for your reply.
That’s exactly what I suspected, and stated in one of my posts, but since I was trying several rendercontrollers at the same time and most of them have a time limit, I couldn’t be very nitpicky about every single parameter, so I had to overall look for what was most easily and straightforwardly configurable and even if I thought that there would be a parameter for “waiting” somewhere (I usually found one in most of the renderfarm controllers I tried) all that changing implies changing, render again, check for progress, change again… damn, now it looks like it’s missing frames, etc, and time was an issue. And since I got much better results “right out of the box” with other controllers I really didn’t allow myself to spend too much time with Deadline, in face of such disparating results (in comparison with others) with the same trouble.

Thank you for the explanation… Now for the funny part! I had Deadline installed, during the tests, for the last 2 months, not touching it for at least more than a month now… So this very weekend I was cleaning up some stuff and that’s exactly when I uninstalled it! Now you come up with a solution!

Murphy’s Law, I guess! Jut like that folder hanging around with example scenes for years, scenes and objects that never got used… and when we finally delete it, the next day we find a use for it!

#12

OK, I really didn’t want to keep this “incognita” in my mind so I reinstalled Deadline and did it another try with the modification you sugested. Then I compared the results with the table i already had done with others and tested with them before.

Again, this was a very small scene! For 2 reasons: first, since I was testing several render controllers, I couldn’t afford renders of hours (or even minutes) several times in a row just to test the render controller, and the reason of the test was really to see how it sended frames to the several cleints, what kind of statistics it had, etc, not a render-speed test, that dependes on the application, but a render controller speed test; second… my scenes are really usually fast… just a bunch of them that will later overlap in compositing.

So, this was a really quick 100 frame scene that takes 1-4 seconds per frame (nothing like 1-hour frames like yours!).

The result in Deadline was some incredible 21 minutes. I pushed it even further and decreased almost everything to 1 (and in some cases even when extreme and put ‘0’ there!) and got 10:25.

The result with Smedge was 4:54 (with 1 client instance and multithreaded) and 3:27 (with one client instance per CPU (as this is a dual core machine).

The results with RoyalRender was 4:54 (doing the scene steping it does by deafult to checking if everything was OK) and 2:33 (without any scene steping, in other words, step=1).

PS: Of course I could send the whole 100 frames to only one computer at a time, but that would defeat the purpose of the test. But for the record, I did it, and it took only 2:04… Of course that in Smedge I also tried it and it took 1:57.

In short, Deadline may have great features for big comapnies with hundres or thousands of machines that crack 24hour frames day after day… but for a poor freelancer that only has a couple cpus availabe and just need fast scenes in queue, and fast tests in thousands of frames, like myself, is just not the best solution, IMHO.

#13

Fair enough!
I will forward this thread to the development team so they can look into improving support for small LW scenes on few CPUs in the future.

Thank you very much for your feedback!

#14

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.