From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Multicore workstations and clever farm use
   Date: Tue, 29 Sep 2009 22:21:07 -0400
Msg# 1899
View Complete Thread (4 articles) | All Threads
Last Next
Abraham Schneider wrote:
> Sometimes it would be really nice to use 4 of the cores to work in the
> GUI and the other 4 cores to render in with rush.

	'rush -reserve' is made for this purpose:
	http://www.seriss.com/rush-current/rush/rush-command-line-options.html#-reserve

USING RESERVE JOBS
------------------
	The CPUS number in the rush/etc/hosts file is really to be thought of
	as the number of instances of the renderer you want to run, so if you
	have '4' in the rush/etc/hosts file, and want to reserve 2 for GUI use,
	you could say:

		rush -reserve localhost=2@200

	..which says reserve 2 of rush's 'cpus' at 200 priority on the local machine.
	This means no job under 200 priority can use those two procs, even if its
	a 'killer' job. If you want to make it so no job can run, use 999.

	'rush -reserve' creates a 'dummy sleep job' that holds the processors
	to prevent other renders from using them. Just dump the job to get rid
	of the reservation.

PROCESSOR AFFINITY
------------------
	However, if you've got multithreaded jobs and are specifying fixed
	numbers on the command line (eg. "shake -cpus 4") then threads might
	still leak into using processors you want "reserved". In such cases
	it can get tricky if you're trying to split hairs.

	The desire here is to really lock physical processors to a particular
	user. eg. if 'fred' is logged in, he wants to make sure that of the
	8 processors on his machine, 4 can ONLY be used by him, so that even
	if a multithreaded shake job jumps on the machine, there'd be no
	chance that his 4 procs get used by the renders, no matter how many
	threads are running.

	Under Windows there's "Processor Affinity" which lets one ensure
	a program only uses eg. 1 processor. One way to do this is with
	the Windows 'start' command, eg. "start /AFFINITY <value>",
	where <value> indicates which processors to lock a command to,
	for instance:

		START /AFFINITY 3 shake -exec /path/to/your.shk -t 1-69

	..which will 'lock' the shake process to cpus #0 and #1. The
	/AFFINITY value is a "bit field" which breaks down this way:

		Affinity
		Value		Cpu#	Binary Value
		--------	----	------------
		1 		0	0001
		2		1	0010
		3		0,1	0011
		4		2	0100
		5		0,2	0101
		6		1,2	0110
		7		0,1,2	0111
		:
		16		3	1000
		17		3,0	1001
		:
		etc.

	There's a chart here:
	http://technet.microsoft.com/en-us/library/cc778499%28WS.10%29.aspx

	There are some other techniques you can do too.

	To simplify things, usually all people want to do is use their
	own machine for rendering, and not allow others to use it.

WORKSTATION SPECIFIC RENDERING
------------------------------
	To do this, a common technique is to use 'rush -reserve' to
	reserve the entire machine at some high priority, say @899.
	Then when you want to render on your machine, submit a job
	that asks for your machine (eg. 'tahoe') at a priority of 900k, eg:

		Cpus: tahoe=2@900k

	..and setting e.g. the -cpus for shake to the number of threads
	you want, so that you don't use the entire machine.

	This will let your render bump the reservation job so that it
	can run, and when the render's done, the reserve job will maintain
	a hold on the processor again.

	If you're trying to set things up so that jobs can run on the
	farm AND on your workstation, but on the workstation, jobs never
	use more threads than you want, you'd have to modify the logic
	of the submit scripts to clamp eg. shake's "-cpus #" so that
	if the render is running on that machine, the -cpus number gets
	limited down to the value you want.

	Also, you can use MINPRI column of the hosts file is something
	you can use as well to put a 'wall' on the jobs the workstations
	accept. The 'MINPRI' value sets a minimum priority a job needs
	to render on that machine. This way the machine's processors will
	remain idle unless a job asks for this machine with a high enough
	priority. You can establish policies that allow users to only submit
	to their own machines with a priority sufficient to render on their
	own workstation, while keeping other renders away.

	If you need more specifics on any of these, let me know.

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

Last Next