From: Christopher Janney <chrisj@(email surpressed)>
Subject: when the submitting workstation dies, so does the render
   Date: Fri, 13 Oct 2006 17:11:20 -0400

Thanks!

-ctj

Christopher Janney
www.a52.com

Christopher Janney wrote:

[posted to rush.general]

We have dual boot win/linux boxes here. Since we work primarily in windows, we do not have rush.d running on the linux side, and I don't think it would even help in this case.

When we submit a job on the windows side, then boot into linux, the frames that are already rendering continue to do so, but the rest of the job is basically paused until that workstations rush.d is started again. This means if that machine crashed in the night, no render in the morning, etc. There has got to be a way around this.

	If I follow correctly, you just want to be able to requeue
	the frames that were running on the box at the time you shut it down?
	ie. after you requeue the frames, they remain in the 'Die' state
	because rush is unable to get a confirmation the render was killed
	because the box is down or dual-booted.

	Simple answer: use the 'Down' button in the irush "Frames" report
	to tell rush that machine is down. Right click on the 'Down'
	button in irush "Frames" report for help.

	Or, from the command line you can use the 'rush -down' command as well:
	http://www.seriss.com/rush-current/rush/rush-command-line-options.html#-down

	Rush does not automatically assume a machine is down if it hasn't
	responded for a while, because often that situation just means the
	machine is under a lot of load (thrashing). It's worse for rush to
	assume a machine is down, when it really is not, as then you get the
	worse situation where more than one machine is working on the same frame,
	the separate machines overwriting each other's work.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

or maybe I am miss reading the e-mail

-Saker



Christopher Janney wrote:

[posted to rush.general]

We have dual boot win/linux boxes here. Since we work primarily in windows, we do not have rush.d running on the linux side, and I don't think it would even help in this case.

When we submit a job on the windows side, then boot into linux, the frames that are already rendering continue to do so, but the rest of the job is basically paused until that workstations rush.d is started again. This means if that machine crashed in the night, no render in the morning, etc. There has got to be a way around this.

Thanks!

-ctj

Christopher Janney
www.a52.com

Saker Klippsten wrote:

[posted to rush.general]

I would tend to guess your box is acting as the submit server? Meaning your machine is controlling your job. I would recommend setting up a couple submit servers that never reboot and are up all the time. You submit your job to eb rendered to these servers, so if your boxes crashes.. rebooted.. whatever you are not affected. To me this is the typical setup for a render farm....

or maybe I am miss reading the e-mail

	Yes, you're probably right, that's what he means.

	Yes, if you submit a job from a workstation, the default is that
	workstation becomes the 'job server' for that job.

	If you shut it down, that job will be frozen until the machine
	comes back up, as it is the manager for the job.

	If a user knows they're going to be shutting their machine down,
	or don't want to use their own machine as the server for their job,
	as Saker says, you can tell rush to use a different machine as
	the job server; in the submit forms there's a field:

		Submit Host:

	..set that to the hostname of some other machine, and when the job
	is submitted, that machine will become the job server for the job.
	Then it would be safe to shut the local workstation down without affecting
	the submitted job. The "Submit Host:" setting will be remembered, so that
	future jobs submitted with the same script will continue to use that
	same setting, unless changed.

	You can also specify a comma-separated list of hostnames at the Submit Host:
	prompt, and the submit script will randomly choose one of those hostnames
	as the job server, so that jobs aren't all focused at one machine.
	This is especially useful on large networks with many jobs, to ensure
	that the load of job serving is distributed across several machines.

	And yes, as Saker said, if this is a common practice, you can
	set up dedicated machine(s) for the purpose of being job servers,
	and you can modify the scripts so that they automatically use these
	machines by default whenever someone submits a job, if you want to
	enforce this for all users.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)