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)
|