From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: specify number of cpus per machine
   Date: Fri, 19 Aug 2011 00:12:45 -0400
Msg# 2118
View Complete Thread (3 articles) | All Threads
Last Next
On 08/18/11 20:34, Greg Ercolano wrote:
> On 08/18/11 19:32, Gary Jaeger wrote:
>> I can't recall how to submit this. Suppose all the machines in the group
>> "fubar" have two physical procs, but we only want to submit to 10
>> machines, and have each of the machines only use a single proc?
> 
> 	That would be +fubar=10.1
> 
> 	The docs for the 'cpus' submit command cover all the possible syntax
> 	for this field:
> 	http://www.seriss.com/rush-current/rush/rush-submit-cmds.html#Cpus
> 
> 	I should probably make sure all the "?" buttons for the "Cpus"
> 	fields in the submit form cover all these options as well.

    Oh, and by the way, that causes /only that job/ to start one render
    per machine. It doesn't prevent /other/ jobs from starting renders
    on the unused procs.

    If you want to prevent that, submit with the Ram value set to
    the maximum amount of RAM rush thinks each machine has. That will
    make rush think your job needs the whole machine, leaving nothing
    for other jobs to use.

    If you have your rush/etc/hosts file set up with the CPUS field
    set to 1, then you don't need to do any of this; rush will only start
    one render per machine (even though the boxes might have 2 or more
    processors, the renders will still thread using both).

    You can set the rush/etc/hosts file with CPUS set to 1 to simplify
    things ONLY if *all* your renders are multi-threaded. (ie. each single
    render on each machine will use of all the processors on that box)

    If, however, some of your renders are single threaded, then to support
    those types of jobs along with multithreaded, you'd want the
    rush/etc/hosts CPUS value set to '2', so that rush can starts
    up to 2 renders on each machine.

    If that's the case, and you have a multithreaded job that you want
    to start only one render per box, and exclude other jobs from
    using it too, then submit with the Ram: value to prevent other
    jobs from picking up.

    For instance, let's say your rush/etc/hosts file has all machines
    with CPUS set to 2 and RAM set to 100 (so that the RAM value
    represents a percentage of the machine)

    To submit a multithreaded job that starts one render per machine
    but threads on both processors, and doesn't allow other renders
    to share the machines, fill out the submit form with:

     Threads: 2
	Cpus: +fubar=10.1
         Ram: 100              <-- this field is under the 'Rush' tab in the submit form

    This way rush will think your job needs 100% of each machine it runs on,
    and will only start one render per box, and the render will start two threads.
    Rush will think all the ram is being reserved by your render,
    so it won't let other jobs share the machine.

    This use of the RAM field in the rush/etc/hosts file as a percentage
    (setting it to 100) works for more complex situations too, so you can
    submit with 25 to use 25% of the machine, or 50 to use 50%.

    This way, you can get patterns of use on each machine
    where you can end up with a machine running:

        * 1 job asking for 100%
 	* 2 jobs, each asking for 50%
        * 4 jobs, each asking for 25%
        * 3 jobs each asking for 33%
	* 3 jobs, one needing 50% and the other two needing 25%
        ..etc..

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


Last Next