Environment Variables

These environment variables are used by the rush system. Some variables(¹) are set by the rush daemon to pass information to the user's Render Script. Render Scripts should at very least make use of $RUSH_FRAME or $RUSH_PADFRAME to determine the current frame number being rendered. Some variables (²) affect the behavior of the rush client program.

 

RUSH_FRAME 1	This variable contains the frame number to be rendered, ie. "1", "12", "104". No padded zeroes are used.
RUSH_PADFRAME 1	This variable contains the frame number to be rendered, and includes 4 padding zeroes, ie. "0001", "0012", "0104".
RUSH_JOBID 1	Contains the jobid of the current running job. ie. "tahoe-37"
RUSH_TRY 1	The number of times this frame has attempted to render this frame; the number in the 'TRY' column of a 'rush -lf' report. Can be changed with rush -try.
RUSH_TMPDIR 1	Contains the path to a directory in /usr/tmp that is automatically created before a frame starts rendering, and is completely cleared after the render completes. Use this variable when creating temporary files in your render script, so that the files are automatically removed, even if your renders are bumped or dumped while in progress. eg: ### YOUR RENDER COMMANDS HERE render -output $RUSH_TMPDIR/foo.rgb post_filter -in=$RUSH_TMPDIR/foo.rgb \ -out=/job/MYJOB/img/$RUSH_PADFRAME.rgb
RUSH_LOGFILE 1	Contains the full pathname to the output log for the render script. The contents of this file grows as the render script generates output, so the render script can, for instance, 'grep' text from this file to act conditionally to serve its own purposes.  See Detecting Render Problems with Grep for examples of this technique.
RUSH_HOSTNAME 1	The local hostname the render script is running on. This is the name that appears in 'rush -lac' reports.
RUSH_FU 2	If set to '1', implies the '-fu' flag for all commands. Not recommended for use in user's environment. This variable is meant only to be used by GUI interfaces that are layered on top of the rush command line tool.
RUSH_DIR 1,2	This variable is the directory name of the rush directory. Normally, this is /usr/local/rush. Appending '/bin' gives a path to the rush(1) and rushd(8) binaries. This variable should be in the user's environment so all rush(1) commands can access it, and as well, should also be set in the boot scripts before rushd(8) is started. Both rush(1) and rushd(8) depend on this variable being set.

¹ Variables passed to Render Scripts.
² Variables used by rush(1).

Priority Description

In general, higher priority values are 'more important'.

Priority values are in the range 1-999. Values outside this range cause an error.

Priority values are generally specified in the 'cpus' command, such as:

cpus tahoe@100
cpus tahoe=1@100

Both of the above are equivalent, asking for one cpu on tahoe at 100 priority. (If the number of cpus is not specified, '1' is the default).

Jobs contend for cpus based primarily on priority. When priority values are equal, the system uses a round robin scheme, using 'first come first serve'.

Priority values are 'relative'. If all the jobs on the network are 100, and your job is 101, it will always win battles for an idle cpu. (Making your job 200 priority will not make it get done any quicker.)

When priority values differ, cpus are arbitrated using these rules:

• Higher Priority Always Wins.
  If two jobs contend for a cpu, the higher priority job always wins. Which implies the next rule..

• Lower Priority Jobs Always Loose.
  The lower priority job will always loose.

• Equal Priority Jobs Share.
  If two jobs of equal priority contend for a cpu, they alternate execution on the cpu.

In addition to the above, 'priority flags' may be appended to the priority values. (eg. 100k, 100a, 100ka). These flags augment the above behavior in the following ways:

• Kill Flag ('k'). The job will kill lower priority jobs immediately, rather than wait for them to finish rendering frames already in progress (the default behavior). A killed frame will automatically be re-rendered on the next available cpu. The 'k' flag is only effective against jobs of lower priority. Where the priorities are equal, the 'k' flag has no effect.

• Almighty Flag ('a'). Disables higher priority jobs from being able to kill frames already in progress during priority battles. Basically, this disables other job's Kill ('k') flags, causing these jobs to rever to the default 'passive' behavior of waiting for an in progress frame to finish.

Priority flags are normally used separately, but can be combined (eg. 100ka) to create the situation known as 'Kick Ass' mode.

Beware: abuse of these flags can be tracked by sysadmins. If you cause trouble by submitting jobs with killer priorities that are not assigned to you, you can be tracked down via the system's auditing logs.

Here are some example situations to demonstrate the above rules.

Priority Scenarios

Example: Passive Higher Priority (Non-Killer) A 100 priority job is running on a cpu. No other jobs are using the cpu, so the job continues to render on that cpu, one frame after the other. Suddenly, someone submits a 200 priority job to the same cpu. The 100 priority job will be allowed to finish rendering the current frame, and then the 200 priority takes over the cpu, rendering all its frames. Once the 200 priority job has completed, the 100 priority job continues to render the remaining frames.

Example: Aggressive Higher Priority (Killer) Similar to the above, a 100 priority job is running on a cpu. No other jobs are active, so the job continues to render on that cpu, one frame after the other. But this time, someone submits a 200k priority job (kill flag is set). The 100 priority job's frame is immediately killed, and the 200k priority job takes over the cpu until all its frames are rendered, at which point the 100 priority job resumes on the cpu.

Example: Equal Priority (Round Robin) Again, a 100 priority job is running, with no other jobs active. Then someone submits a different job at 100 priority. Both jobs will alternate using the cpu, yielding to each other. Note: Even if either or both jobs had their 'k' flags set, the behavior would still be the same, since the priority of both jobs is equal. (killer jobs will only kill lower priority jobs, not jobs of equal priority)

Host Groups

Host groups allow TDs to specify groups of hosts that a resource manager or sysadmin maintains, rather than specifying hosts by name.

Host groups are free-form names defined by agreement between TDs and sysadmins.

Host groups are used like hostnames, and always start with a '+' character, as in:
 

cpus         +soft@100
nevercpus    +neverhosts


All hosts on the network should be a member of the special host group name '+any'. So if a TD specifies  '+any=10@500', this indicates the job wants to use any 10 available cpus at a priority of 500, taking into account limitations set by the submit script's criteria and neverhosts commands.

For example, if the resource manager creates a hostgroup called +badlands, adding several hosts as members of that group, then TD's can put in their submit script:
 

cpus +badlands@100


..to inherit all hosts configured in the +badlands host group at a priority of 100.

Host groups can be specified in the following submit script commands:
 

• cpus
• nevercpus