BackBurner Probleme...

[UbiGuy]

Anyone have experienced problems between BackBurner and Vray?

When I render on the renderfarm. Suddenly the manager stop sending scenes to some servers. Without any warning or error message, the manager suddenly "forget" some server.

After few minutes or few hours only 2 or 3 nodes still rendering. The others nodes apears Yellow (idle) and no error messages apear. I have verify and it's not because Backburner have already assign the working node to the remaining jobs or frame to renders...

I'm not sur but this bug seem happening only on heavy or long render. I never saw this problem before.

Thank you for your help.

[instinct]

Did they throw errors before ? (check the error tab of the corresponding job). Backburner automatically pulls servers from job after a certain amount of errors.

Regards,
Thorsten

[UbiGuy]

Nope... No error at all...

Backup Burner at end only keep one render Node active. And has I said, the remaining frames are not already assign...

It's really a strange behaviour...

I appologize for my bad english...

[dbibb]

That sounds like a problem we had awhile back. There were plenty of jobs in the queue, but not all the servers were kicking in. What version of BB are you using? I think that happened for us with the version that shipped with max9. There was a service pack for that one which fixed it.

I can't remember completely, but some people fixed problems with it by reverting only the manager back to an older version.

[UbiGuy]

Maybe I can try that... But I don't have a lot of time to put on a complete BackBurner re-install of the renderfarm...

We have the last service pack...

I will try to re-install it first on de manager Node... I will se after...

Thank You!

[devin]

I have the exact same problem and I've got the latest SP installed.

[emptyvoxel]

We recently set our manager up on a 64-bit machine (to get around the 600 minute task timeout issue), and the first job I rendered over the weekend had the same problem you describe. About 20% of the render farm just went idle and refused to be reassigned. I read on the Area forum that some people got around it by suspending the job and restarting, but I haven't had a chance to confirm that yet.

I never had this particular problem with a 32-bit manager. Only other problems.

[devin]

I'm running Max 9 32bit so it's not just limited to the 64 bit version, and I can confirm that restarting the job usually fixes the problem at least on that job.

[joconnell]

It's not doing anything weird like allocating blocks of frames is it? It's a default preference in the submit dialog of backburner under advanced where it'll assign 10 frames to one machine, ten to another and so on rather than each frame going to the next free machine.

[devin]

No it will stop sending frames to where only one or two machines are actively rendering when there are hundreds of frames left.

[tricky]

Anyone got any other tips for these backburner issues? We get Application Load Timeouts occurring regularly, but 95%-99% of the time these only occur on dual quadcore machines (running XP64). Its really frustrating as I set a whole lot of jobs rendering overnigh/overweekend and come back to find that our fastest machines have been idle for most of the time!

We are using Max2009 64bit SP2 on all machines with Vray 1.5 SP2 and I am rendering the frames from a saved lightcache solution (but the primary bounce is brute force).

BB is version 2008.1

[tricky]

When I look at the BB Server screen on the offending machines, I get the message:

Server has not received an update from the manager and has timed out; assuming the manager is down.
Manager is not responding.

I can't be sure that this happens all the time, but on checking this morning, it vertainly seems to be the case.

[tricky]

Me again! The BB Manager program runs from our server which is on Windows Server 2003. It is not 64bit. Could this be an issue?

[gilpo]

Our manager is run on Windows Server 2003 32-bit and no problems here. The only time we get the "manager down" message is when we cancel a job or remove a render node from a particular job, then it freaks out a little. This happens mostly on our dual quadcore machines (as you noted) however, it will pick back up after a few minutes.

We had the application load timeout when we first started building a farm because our machines were to slow to load the file before the manager gave up on them. However, that shouldn't happen on your machines. How much ram do they have? For a dual quad, 4 gb is the minimum. Treat it like each core is its own system. With 4 gigs, that means you have 8 cores with 512K ram each. This has been fine for us, but we do have scenes on occasion when these systems render slower than they should because of this. In reality, 8gb of ram would be better and we will probably upgrade soon.

If I remember right, there was a setting somewhere that set how long the manager would wait for the server to load the scene and start rendering. I don't know if it's in the job settings when you submit the job or in the manager settings. You also might look in the backburner.xml in the network folder in the backburner install directory on the manager system. There might be a setting in there to try.

It could also have something to do with your network speed. Remember, that the manager has to distribute the file over the network to all the nodes and if it takes too long, the manager might give up on them.

That's all I can think of right now. Good luck.

[tricky]

Thanks for your post. The machines giving the problems are all 8gb, so I am hoping that isn't the problem. I'll have a look at the application load settings, but to be honest, I am pretty sure it defaults to 20 minutes which is far far more time than it takes to load the scene. I suppose it could be network bottlenecks, but we are all gigabit networked here with cat6 cables, and so it should be fine.

The main thing is it seems to be these dual quad-core machines only and not the dual dual-core which have just 4gb ram. Very odd. I hate the way that BB is sooo difficult to troubleshoot.