GPU requires this user logged in

(if client is running in App Mode)

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

And is NOT running as background 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 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.

Reserve cores if user is logged in

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

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. 
Which means each core gets two tasks at the same time. 
So in case of hyper-threading, you should reserve at least 2 cores.

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. 

Pre/Post/Finished Scripts

By default, a client does take jobs it is assigned to. 
It does not matter if the job state is the main render or a pre/preview/post/finished scripts.

You can change this behavoir with this option

Hints:  

• You can use older machines as script-only machines.
• You can restrict a job thread of a client to accept script only

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)

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 less than

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 x minutes
...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.

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 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".

About the CPU usage threshold:

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.

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.