Icon

This is the documentation for an older version of Qube. The latest version of the documentation can be found here: Qube

Skip to end of metadata
Go to start of metadata

Qube does not explicitly restrict a job to run on a particular core. It leaves that up to the applications to determine. If this is the case, then what to these terms used in Qube mean and how do they relate to machine cores?

The terms can be misleading. Here is a summary of the terms and their meanings:

  • Job Terms
    • CPUs: This is the number of (render) processes to concurrently run. Those processes can use multiple cores, though that is left up to the processes. It does not have a direct relation to the number of machine cores.
    • subjobs: These are the actual processes being run by the jobs. They are not a dependent or child job, but rather a process parented under a job.
    • reservations host.processors=1: This is the number of process slots (see below) used for each job process. If one sets in the job host.processors=2, then each process for that job will use 2 process slots (though not limited to 2 cores). Reservations can also be used for reserving things like memory or licenses for each process.
  • Worker Terms
    • host.processors: This is the number of subjobs or process that can run concurrently on a Worker. Think of them as "process slots". It is not directly tied to the number of cores on the Worker, though it is set by default to the number of cores on the system. To have a worker run only a single render process, but with the capability to use all the cores, set host.processors=1 or lock the Worker to only have 1 unlocked slot.

Putting it together...

The job's CPUs value refers to the number of subjobs (or processes) the Supervisor should dispatch to run the job. Every job has at least 1 subjob/process, and each subjob/process runs in a slot on a host. The number of subjob slots a single subjob takes up is controlled by the host.processors resource reservation. By default a single subjob takes up a single slot (host.processors=1) when submitting a job.

Therefore...

When you submit a job and request a number of "CPUs," you are not actually asking for Qube to map processes to processor/cpus/cores. Rather the "cpus" value is represents the number of "subjobs" to dispatch to various Workers. By default, each subjob takes up one "slot," the number of slots on a Worker determined by the "host.processors" resource. That value is set by the worker_cpus configuration variable. If it's set to "0," then host.processors is automatically set to the number of cores on the Worker. Any other value is what host.processors is set to.

That's why every job by default has a reservation of "host.processors=1" It means "look for a worker with 1 slot open, and then fill it with a subjob, and reduce the number of slots on the Worker by 1."

When a subjob launches, Qube is executing an instance of an application, which may be a simple command line, or it may be an elaborate interactive session with Maya (Maya Job Type). At this level, we are simply running the application, and depending upon the OS to determine actual CPU utilization.

Now for a practical example...

To have each Worker on your Qube farm render a single frame at a time using all cores (with a multi-threaded renderer like Maya), just reduce the number of available host.processor resource slots on the Worker to 1. This can be done by "Locking" off the number of available process slots to 1 (done through the QubeGUI or commandline).

  • No labels