Jobs

Parent Previous Next


Enable/Disable

Allow Little Jobs if client is disabled

You can mark jobs as "Little Jobs" at submission. These jobs will render on a client even if the client was disabled by the Artist.

As the render process is running with low priority, the artist logged in should not be disturbed by the CPU usage itself (He can be disturbed by memory usage and network load).

This feature can be used for jobs that use a small amount of memory and do not require to load big scenes or textures, but still have a high render time. 

Disable if CPU usage is high

If the client is not rendering or if the client finished a task:

    If the CPU usage of the artist is higher than xx % for 15 seconds, then the client will not accept new jobs. xx can be set with the "CPU usage Limits".

If the client is rendering:

    It will abort jobs if the CPU usage of the artist is higher than 85% within 4 minutes.

   (It does not have to be 85% all the time, but at least at the beginning and end of the 4 min check range).

Disable if available memory is low

If the free/available memory of the system is lower than x GB, then the client will not accept new jobs.

If the client is already rendering, then it will NOT abort jobs.

Auto-Enable after low CPU usage for


...and no user interaction for

If an artist is logged in, then the artist can disable the client (If you do not use the Working Hours setting). 

But artists tend to forget to re-enable the client. 

Therefore the client can re-enable itself after some time.


Note: The "Low" CPU limit can be set on the same rrConfig tab.



"...and no user interaction for":

This function requires the rrClient running in application mode within the artists session 

or requires rrClientWatch to be running within the artists session.

RR requests the last user interaction of the user like mouse, keyboard inputs from the OS. (It is the same/similar function that is used to enable the screensaver)


Depending on the "...and no user interaction for", you notice a slightly different behavior:

  • Disabled (Or Linux) "and no user interaction for"  
    In this case "Enable after low CPU usage" is the only way to enable the client if the machine is idle.
    But there is a catch: You have to set the  "Low" CPU limit to a low setting like 0.5 cores to catch for example Photoshop work.
    And it has to be lower than 1.0 to catch every non-multi-threading application.
    E.g. Animators do not render and might not use more than 1 core.

    On the other side, there are background tasks of the OS, the artist might have kept 40 Firefox/Chrome tabs open which update all the time or has opened an 2D/3D application that updates the viewport all the time. In this case the CPU usage might be above 1 core from time to time. And therefore client does not enable itself if you have set the  "Low" CPU limit to less than 1 core.
    But a setting higher than 1 core conflicts with the above requirement to catch Photoshop work..


  • Enabled "and no user interaction for"  
    The CPU usage has to be lower than the "Low" CPU limit AND there should not be any user interaction.
    It is recommended to use a  "Low" CPU limit of e.g. 1.5 - 2.0 cores. (Not too high because of the "Job frozen" detection)
    If the artist is using the workstation, it does not matter how much CPU he uses, the rrClient is kept disabled.

    If the artist starts a simulation/rendering that takes 3 hours and goes away, then the rrClient does not enable itself as long as this process uses more CPU than the "Low" CPU limit.


Abort job if system memory is low (recommended for stability)

If the client is rendering and the system memory gets low, then the client will abort the rendering.


Windows: The system cache is lower than 75MB and the free memory lower than 500 MB OR system cache+ free memory is lower than 125 MB.

Linux, Mac: The free memory lower than 50 MB.

Disable if processes found.

You can enter multiple process names separated with a ; 

If the client finds this process, then it aborts all jobs and disables itself.

Note: On Linux, the symbolic links to executable are resolved. For example if you start python, the executable is python2.6, not python.




Abort Jobs


Abort job if system memory is low  (recommended for stability)

Is the system memory usage is lower than an internal defined value, then the system gets instable.

RR should abort the rendering in this case to keep the OS runnig.


Abort jobs with low CPU after x Minutes (frozen)

A render application can sometimes freeze. It just sits idle and does nothing. It does not continue to render nor does it exit.

If the client recognizes that the render application did not had y% CPU usage for x minutes, then it aborts the render as "freezed".


% CPU limit:

The % CPU limit is set in the client config, group "CPU usage limits", "Low".  

But most render applications override this setting in the render config.



Do not use all cores if a user is logged in

Reserve cores if user is logged in.

You usually do not use all of your 4 (8, 16, ...128) cores for work, most of the time maximal one core.

So why keep the other cores unused?


The client offer a switch to keep core free from RR renderings. And of course the other cores still run with low/idle priority, so if you need more power, you get more.

By default, the reserve core option is used as long as somebody is logged in.  (You can change that it is only enabled during working hours if someone is logged OR that it is always enabled during working hours, no matter if someone is logged in or not.)


Note: 

This feature can not control the network access. So if you do compositing or simulations and these load a lot of files, then the network can get slower for other processes on that machine. 

This is the same for the installed RAM of your machine. If the RAM is heavily used, the artist will notice that the client is rendering.


Note: 

If you have hyper-threading enabled in your system and your task manager shows 16 cores, then you only have 8 real physical cores. Each core gets two tasks at the same time. So if you render with 8 threads, then all cores are used. So the value should be higher than on systems without hyper-threading enabled.

Apply "Reserve cores" during working hours only

By default, Reserve Cores is applied if somebody is logged in.

You can combine it with working hours. In this case, somebody has to be logged in AND the current time it has to be within working hours.

Apply "Reserve cores" during working hours even if nobody is logged in

By default, Reserve Cores is applied if somebody is logged in.
This disables this requirement during working hours. 






CPU usage limits

High

Used for "Disable if high CPU"

Low

Used for "Auto-Enable after low CPU usage for" and "Abort jobs with low CPU after/Job frozen" detection.

Note - Job frozen:

Most render applications override the cpu limit for the freeze detection in its render config.


Note - Auto-Enable after low CPU usage for:

Most OS have background tasks running which use up to 1 core from time to time.

Some OS have a lot of background applications running, Artists could have opened an 2D/3D application which constantly uses some CPU, Artists could have opened firefox/chrome with 50 tabs that all update something.

Therefore we recommend to set it higher than 1 core to detect renderings only. But not too high because of the "Job frozen" detection.






GPU rendering

These settings affect the decision of the rrServer if it should send jobs with the "GPU required" flag to a client.

Please see GPU rendering as well.


GPU available if running as service


This setting has an effect if the client is running as service/deamon.


If you have an older graphics card or driver, then you cannot use your GPU within a service.

Or some applications like After Effects can not use the GPU if it is running as service.

In these cases, you can enable this option.


GPU requires this user logged in

(if not service)

This setting has an effect if the client was started via a startup script or manually.

And is NOT running as service/deamon.

Some companies have setup a render user account. E.g. An artist logs in and requires the GPU. Therefore the client should not render. After the artist are done in the evening, they login with the render user. Which tells RR that is can send GPU jobs to that client.

Local Copy

Local Scene Cache:

This is a job setting that is enabled by default for most render applications.

The rrClient copies the scene file before it opens it for rendering.


Local Textures:

If a job contains a local texture list, then these files are copied before rendering the scene.


Local copy slowdown

RR is able to slow down all copy operations.

This is requires to reduce the network traffic for a fileserver if x clients access files at the same time.

Some fileserver cannot handle that much traffic and return empty data otherwise.

Custom Local Textures folder

Override the default folder RR_localdata\textures\.

The folder can be a shared folder as the copy function is respecting multiple clients trying to copy the same file at the same time.

Custom Local Scenes folder

Override the default folder RR_localdata\cachedscenes\.

The folder can be a shared folder as the copy function is respecting multiple clients trying to copy the same file at the same time.


Misc


Privilege for Jobs of

Jobs with this user/project/renderApp name have the highest priority on this client.

The client will render other jobs, but only if there is no active job of this user/project/renderApp.

If the client is rendering an other job and you send a job of the privileged user/project/renderApp, then the rrServer will abort the other job on this client.

Pre/Post/Finished Scripts

By default, a client does take jobs it is assigned to. For the render and for the pre/preview/post/finished scripts.

If you enable this option, this client takes all or no scripts jobs.

No matter if it is assigned or not for the job.

Hint:

You can use older machines as script-only machines.

Wait ... sec. after a new job before requesting a job for an other thread

If one thread has got a job, you can tell the client to wait x seconds before any of the other threads gets a job.

This is required for 

  • Some applications do not support that they start multiple instances simultaneously.
    E.g. After Effects closes with some error if you start two instances at the same time.
  • Starting an application and loading the scene takes a lot of the capacity of the harddrive and the network.
    E.g. if two applications try to take all capacity they can get from a harddrive at the same time, they do not get 50% each, they get about 35% of the harddrives speed. (The missing 30% is just lost)