Frame ranges and qube!'s --cpu option

[turi]

I think I experienced similar problem (if I understand correctly what you are trying to say) but with lightwave and I believe is a problem with how qube behaves. For e.g. try to render a single frame but assign 2 cpus. So your command is going to look like "qbsub --cpus 2 --range 1-1 <your program command>". What qube does in this instance is actually start the process on two cpus and both work on the same frame and in the end only one subjob finishes and other one gets automatically killed. This is a qube feature, which is as you you can guess not smart enough. Now I believe you can overcome this problem if you write your own scheduler and not depend on the one that is provided with the default qube installation.

Another reason you might want to write your own scheduler is that qube is not "that" smart to recognize or use all the available resources. Now I might be wrong, but it is atleast my experience. To get my point across - try to submit a job via command line and do not specify the number of cpus. So you command might look like "qbsub --range 1-300 <your program command>". Now lets say you have a 50 processor render farm. In my experince, qube was utilizing only one cpu for all the 300 frames. It was not even bothering to look for idle cpus at all. I had to specifically mention to use other cpus with the --cpus option. Now this is definitely a major drawback in my situation where you have multiple users trying to submit huge amount of frames and every one trying to specify all the available cpus. Not an ideal situation.

I am trying to play with my own algorithm but I have just started to look in to the api so it'll be a while before I get something to show. If any one else has other insights or feels that I am wrong, I encourage you to correct me.

[anthony]

Hey Turi,

     This felt like a separate topic, so I've split it off and will answer it individually.
 
     You're right about what happens when you submit a job to the queue like this:   qbsub --cpus 2 --range 1-1  <command>

     The system will start the job on 2 hosts and the first subjob will get the frame, and the second subjob will exit because there was nothing left to do.  We're actually going to address this one directly in a later release. 

     In answer to the second question, actually users are allowed to submit jobs which will auto-magically take up the entire farm.  This is done using this syntax:

    qbsub --flags expand  --range 1-100 <command>

    The job will start with 1 cpu and will expand until the first subjob completes.  This allows you to submit jobs which will fill up the farm.  If you prefer this behaviour, you can always setup a default submission flag in your local qb.conf file.

    Please continue to submit questions,

    Thanks,
           Anthony

[turi]

    qbsub --flags expand  --range 1-100 <command>

    The job will start with 1 cpu and will expand until the first subjob completes.  This allows you to submit jobs which will fill up the farm.  If you prefer this behaviour, you can always setup a default submission flag in your local qb.conf file.

That solves a lot of issues for me, thanks. But here is a followup. So does this command look for free processors throughtout the lifecycle of the whole job? For e.g. lets say initially the job occupied only 5 processors but half hour later 10 more processors freed up - will the job automatically use the other free processors too?

[anthony]

Hey Turi,

    Actually, the system's method of expansion works like this:

       If a new bunch of cpus comes online, (jobs quit, processors unlock ,etc...)  we look into the queue to see who's ready to start.  The jobs which don't fit these new cpus (os version ,etc... ) are filtered out and we then look at who has the highest priority.  If a job which has expand is at the top of the list, new subjobs are created and the job is dispatched to these cpus.  The catch however, is the job cannot have any failed or complete subjobs.  This tells the system that the job is already out of frames to do, so it will not expand the job.  It's a relativly simple mechanism, but it will only add subjobs when necessary.
 
     So in my usual round about manner to answering a persons question,  Yes. It will take those free processors.  (Assuming that it has the priority to do so)

     Keep the questions coming.

     Thanks,
         Anthony