From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Multicore workstations and clever farm use
   Date: Thu, 01 Oct 2009 17:15:27 -0400
Msg# 1905
View Complete Thread (0 article) | All Threads
Greg Ercolano wrote:
> 	[..] you can go into the Task Manager, right click on the
> 	'rushd.exe' process, and assign it an affinity for cpus #0 and #1.
> 
> 	Then all renders rush starts will be forced to /only/ use those
> 	two processors; the other two processors will be idle, and
> 	available for interactive desktop use.

   I played around with this a bit yesterday, and it seems to work
   quite well for restricting processors, and this is something you
   all can do with the current release of rush you have.

   In fact, the above should be able to work for all render managing
   software, or any processes, including interactive renders.

   I decided to add an option into the current alpha release of Rush
   (that will go into beta very soon [RELEASED AS 102.42a9c -ed])
   where you can include an optional "processor affinity" setting 
   in the far right column of the Rush hosts file, eg:

#Host		   Cpus	Ram	MinPri Criteria/Hostgroups                                   Affinity
#-------------	   ----	-----	------ -------------------                                   --------
ta                 4    100     0      +any,+erco,+linux,linux,linux6.0,intel,dante,+farm    -
geneva             1	100	0      +any,+w2k,+work                                       affinity=1
meade              8    100     0      +any,+erco,+linux,linux                               -	
superior           2    100     0      +any,+erco,+winxp,winxp                               affinity=3
[..]

   ..the new 'Affinity' field at the far right being the new option.

   Here it shows host 'geneva' that has 2 physical processors, but rush
   is set up to start only one instance of a render, and will restrict
   rendering only to cpu#0 (due to affinity=1), leaving cpu#1 available
   for interactive use.

   Also, 'superior' which has 4 physical processors, but will only start
   two instances of renders, and those renders will be restricted to only
   using physical cpus #0 and #1 (due to affinity=3).

   This way the new release of rush will be able to let the admin force
   it to only use certain physical processors.

   Note the affinity value is a *bit field* that represents each
   physical processor. So for instance 'affinity=4' does NOT mean 
   "use 4 procs", it means "use only processor #2". (See table below).

        Affinity                                             -- CPU# --   TOTAL
        Value (hex)     Cpu#            Binary Value         0 1 2 3 4 5  #CPUS
        -----------     ----            ------------         - - - - - -  -----
        1               0               00001                X - - - - -    1
        2               1               00010                - X - - - -    1
        3               0,1             00011                X X - - - -    2
        4               2               00100                - - X - - -    1
        5               0,2             00101                X - X - - -    2
        6               1,2             00110                - X X - - -    2
        7               0,1,2           00111                X X X - - -    3
        8               3               01000                - - - X - -    1
        :               :                 :
        f               0,1,2,3         01111                X X X X - -    4
        10              4               10000                - - - - X -    1
        11              4,0             10001                X - - - X -    2
        :
        etc.

   Also note the affinity value is in *HEX*.
   This is to be consistent with the syntax of Microsoft's 
   'START /AFFINITY' command.

   So if you set 'affinity=3', "rushtop" will show all rush rendering activity
   locked to the first and second cpu bars (cpu #0 and #1).  You will see this
   same 'locked' behavior in the "Task Manager" as well.

   In my tests with the above alpha release, the task manager showed
   multi-threaded renders started by rushd were indeed restricted
   precisely to the cpus the 'affinity=' setting defined.

   ** NOTE                                                                   **
   **    However, practically, I'm not sure how useful this is.              **
   **    Despite the restriction leaving cpus completely idle,               **
   **    while renders were running, I still could "feel" slowness from the  **
   **    machine during interactive use, even though the 'render' was only   **
   **    doing a sin() computation in a tight loop, not using any I/O, ram,  **
   **    or networking.                                                      **
   **                                                                        **
   **    So even when you get the control you want, it may not get you the   **
   **    results you want. So forcing cpus to be idle won't necessarily      **
   **    get you responsiveness. It probably depends on the mother board     **
   **    I/O config and physical cpus (cores vs cpus) configurations.        **

   [[EDIT: MADE THE ABOVE NOTE IN BOLD          - 11/16/2010 -erco]]
   [[EDIT: ADDED RELEASE VERSION CLARIFICATIONS - 11/16/2010 -erco]]
   [[EDIT: ADDED TABLE OF AFFINITY VALUES       - 11/17/2010 -erco]]

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