- How stable is Qube!?
Very – Qube! has been used in production continuously since 1999. While we continue to extend the capabilities of the system, stability is our primary concern. Also Qube! is backed by a MySQL database that provides the scalablity, reliability and the recoverability of an enterprise database.
- Is Qube! flexible and customizable?
Qube! is extremely flexible. It has APIs (Application Programming Interfaces) in Perl, Python, and C++; you can create your own clients for submitting or monitoring jobs, create custom Job Types, or create reusable templates for linking job dependencies. In addition, the queuing algorithm itself is modular, and can be replaced with your own custom algorithm. All of our clients and Job Types are built with the same APIs no other system provides that level of power and flexibility.
- Can Qube! scale?
Qube! has been used in production environments of up to 2000 machines, and tested using tens of thousands of virtual machines, using a single Supervisor node. Some of the world’s largest render farms in production today are running Qube! on many thousands of CPU cores. A client recently (March 2011) completed 751,000 work items in 7 days on 4,800 cpu cores running Qube! verison 6.1.
- What programs do you support?
Simply put, Qube! can run any program that you can run on your computer. We also provide plug-in interfaces (which we call a “job type”) that allow artists to submit jobs directly from within their applications. See the “Job Types” page for a complete and updated list.
- What are Job Types?
A Job Type uses the Qube! API to link a job submission front-end interface with a back-end execution module. Because the Job Type uses the API, we are able to create submission interfaces to run natively within a variety of applications. Likewise, our execution modules are tightly coupled with the application, often down to the frame level, making them extremely efficient and flexible.
- Can Qube! handle Satellite or Distributed Bucket Rendering?
Rendering a single frame or image across more than one server to decrease the render time for large, high-resolution images is known as “satellite rendering.” When rendering with Maya Unlimited and mental ray for Maya Satellite, the Qube! Maya JobType allows you to dispatch a single frame to as many as 8 additional networked cpus. This workflow can decrease render time required of a large image significantly. When rendering with 3ds Max DBR, a single frame can also be rendered across up to 8 networked CPUs.
- What platforms do you support?
Updated platform support is HERE.
- What level of application integration do you offer?
Our Job Types combine the Qube! APIs with the leading animation software to produce the tightest integration in the industry. This high level of integration gives artists the most natural interface for submitting jobs, and gives engineering the most efficient execution environment for running jobs. Qube!’s SimpleCMD interface also allows quick and easy integration with any application that can execute a command line.
- Is Qube! cross-platform?
Absolutely. Unlike other render managers that require a Windows server or a Linux server, Qube! is truly cross platform. Windows, Linux and OSX are fully supported. Every component of the system can communicate with every other component, regardless of the OS it’s running on. You can have any combination of Windows, Linux and OSX for the Supervisor and Workers.
Can I include my workstation in the farm? If so, how?
Any machine can be added to the farm; you’re free to install the Worker software on any machine in your facility since our licenses are floating. High-performance desktop workstations can be locked out of the farm while artists are working on them during weekdays, but can be made available during evenings and weekends.
Can I create my own job dependencies and priorities?
Yes you can create your own job dependencies and priorities. There are three ways:
1. Set the dependency field when submitting jobs from the QubeGUI to have it have a per-job or per-frame dependency before it starts running (easy to do)
2. Set the –dependency argument with qbsub from the commandline
3. Use API such as perl or python to construct free-form dependency callbacks
What kind of machine do I need for a Supervisor?
It depends on the number of Workers and other clients you’ll be running. The Supervisor is quite efficient, though generally speaking, increasing the RAM in a machine will improve performance more than a faster CPU. A single Supervisor will be sufficient for over a thousand clients. A typical Supervisor servicing 500 multi-core Workers might be a dual-CPU quad core machine with 16GB of RAM and striped local disk for the database. Contact firstname.lastname@example.org for more information.
Can a Supervisor also be a Worker?
Yes, but this is not recommended. While the Supervisor itself does not put a heavy load on the machine, a job being run by the Worker may do so, and that load may compromise the performance of the Supervisor.
- Can I create my own queuing algorithm?
Yes, the Supervisor is designed with a plug-in architecture to allow you to insert your own queuing algorithm. While the Supervisor’s queuing algorithm is designed for maximum throughput and efficiency, and can be tuned according to several different criteria, it’s possible to insert an alternative (e.g. a simple FIFO, non-prioritized priority, or a sophisticated algorithm based on studio-specific meta data or other criteria). See the Development documentation, or contact email@example.com for more information.
- Can I pre-empt jobs? If so, how?
Jobs may be preempted as a matter of course, according to their priority. If there are no available machines, a waiting job may preempt a job of lower priority. The system can be configured to preempt jobs immediately, or after completing the current piece of work (e.g. frame). Some types of jobs (e.g. long dynamic simulations) can be flagged as “non-preemptable,” in which case the Supervisor will select a different job to preempt. A job can also be preempted, that is, made to release the host it’s running on manually, using the “qbpreempt” command, or the Qube! GUI, or via the API. Refer to the documentation, or contact firstname.lastname@example.org for more information.
- How does Qube! manage licenses?
Before dispatching a job that requires a licensed application, Qube! can query the application’s license server (e.g. FlexLM) to ensure a license is available. (Other systems either dispatch the job regardless in which case, if no license is available, the job will fail – and, if resubmitted, will go to the end of the queue or they require you to “wrap” desktop invocations of the application, to keep their system informed of licenses used on the desktop, which is error-prone and inaccurate). You can also reserve a fixed number of application license for desktop use, so a full farm doesn’t mean artists are sitting idle at their desktops.
- How hard is it to kill jobs?
Killing jobs is easy through the command line tool (qbkill), the Qube! GUI, or the API. Users can only kill (or preempt) their own jobs. Qube! administrators can control any job in the system.
- What if the Supervisor crashes, what happens to the jobs in the queue?
The Supervisor is backed up by a journalled MySQL database. When the machine comes back up, it will automatically restore the latest recorded configuration, and query the Workers for updates that occurred while it was down.
- What happens to my jobs if a Worker machine crashes?
If the Worker goes down, any subjobs running on that machine are automatically marked as unfinished and reassigned to other machines.
- Can I dedicate certain resources to specific productions or projects?
Qube! supports a patent-pending system of “permeable clusters,” whereby machines can be assigned in a hierarchy to particular departments or productions. Jobs submitted to those groups or productions will have preferential access to those machines, but if jobs assigned to a different cluster are waiting, they will take advantage of any free machines in other clusters. In this way, maximum utilization of resources is achieved, while ensuring preferential access (and a guaranteed minimum number of machines) to each department or production. In addition, these clusters can be dynamically reconfigured without restarting the Supervisor or Workers.
- Do I have to use the GUI?
No. The Qube! GUI is free for all users, but every operation in the GUI is alternately available in the command line tools, or the API.
- How is Qube! licensed?
Qube!’s licensing is broken down into supervisor and worker licenses; clients (machines which only submit or monitor jobs) are unlicensed.Every Qube! supervisor needs its own license.- Qube! worker licenses are floating, and are tracked on the supervisor. No need for an external – license server.
- The Qube! submission and monitoring interfaces (eg., ArtistView and WranglerView) are unlicensed.
- All of the Qube! jobtypes are unlicensed and may be installed on an unlimited number of machines that will act as Qube! workers.
- Installing Qube! on a client for job submission does not consume a license; you can submit and monitor jobs from an unlimited number of machines.
- Installing the Qube! worker on a machine does not consume a license. You are free to install the Qube! worker on an unlimited number of machines.
- A license is consumed by a worker for every 2 processor sockets on a machine. Hyper-threaded processors do not increase the license usage, it’s based on physical processor packages in a socket.
- When the last job on a worker finishes and the machine once again has no jobs running on it, all worker licenses are released.
- If all worker licenses are in use but there are idle hosts, the supervisor will not dispatch jobs to those idle hosts until worker licenses are freed up.
- So how many licenses should I buy for my farm?
A good rule of thumb is to buy one license for each machine that you want to do work. If you want to extend the peak capacity of your farm (to include desktops, for example), you can quickly rent or buy more licenses. You may rent licenses on demand 24 hours a day / 7 days a week online.
- Can you lease or rent Qube!?
Yes you can and you can do so HERE
- Do you offer support?
PipelineFX offers an extensive online support forum, email and phone support, documentation, examples, and tutorials. Under support, all major and minor releases of the software are included.
- Do you offer training?
Yes. We hold QCA (Qube! Certified Administrator) certification classes regularly. The classes are held just before NAB in Las Vegas and before Siggraph each year, and in various major cities around the world. QCA classes cover installation, configuration, troubleshooting and best practices for render management. Private classes can also be purchased for your company with a minimum of 3 participants. Contact email@example.com to check the current training schedule and to find a class near you.
- Do you offer Consulting?
Yes. PipelineFX offers consulting on-site or via remote sessions under our Jumpstart program. Our consultants are extremely experienced pipeline render engineers who have delivered films, games and TV shows as a part of world-class studios. Contact firstname.lastname@example.org for more information.
- How can I demo Qube!?
Request a demo HERE.
- How much does Qube! cost?
The Qube! Base Render Management Package Supervisor (one per site) is $3,500 USD which includes 1 Supervisor, MySQL, 5 Workers and Subscription for one year (which includes all software updates plus technical support). The Workers (one per host doing concurrent rendering) are $300 per license with $60 per year for subscription. Subscription is REQUIRED for the first year and must be purchased on the initial order. All prices are in U.S. dollars.
- What are your system requirements for the Supervisor?
Supervisor, Worker and Client requirements are HERE.