From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: cpu balancing script
   Date: Wed, 06 Jun 2007 16:15:34 -0400
Msg# 1583
View Complete Thread (16 articles) | All Threads
Last Next
Antoine Durr wrote:
>> maxcpus 2
>> cpus    tahoe=1@999 ontario=1@999
> 
> Beyond their own machine (which is important) I really dislike the 
> notion of a user having to know or choose what machines their stuff 
> lands on.

	Agreed; but if you have e.g. node locked licenses,
	it at least ensures only those boxes get the renders.

	If you have floaters, then yes, you wouldn't specify
	hostnames, just a cpu cap.

	Thing is, if you submit two jobs that are both houdini
	jobs, and you only have two floating lics, then you
	need some 'centralized' way to count the lics; this is
	where a watcher script might come in, and realize there
	are two houdini jobs and limit the procs, or tweak the
	priorities to prevent a situation where more than two
	are rendering at once.

	Rush itself doesn't maintain a centralized perspective
	of things, so it can't do centralized stuff like counting.

> I'm curious as to the different ways that exist.  What kinds of things 
> are important to people?

	I've seen a variety of requests too numerous to mention.
	I think Esc had the most complex of all the scheduling
	algorithms I'd come across for The Matrix III. They had
	all kinds of stuff in there; taking ram into account,
	render times that change over time, I think they were
	even polling ram use as the renders ran. The guy who was
	writing it had a lot of high level goals.

	Trouble with their implementation was they had >500 boxes
	on their farm, and were throwing all the jobs submitted
	to one box..! I warned that was a bad, bad from the get go,
	but they locked into that for some reason. The whole point
	of rush's decentralized design is to distribute the job
	load, so it really hinders it to focus all jobs on a single
	box for a large net. This made it tough for them, because
	the central box became overloaded fast, in addition to their
	watcher constantly rescheduling it.

	That was a while ago, 2002/2003 IIRC, when boxes and
	networks were slower, and rush has had some optimizations
	since then.

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

Last Next