Am 21.02.2011 um 11:31 schrieb Chris Jewell:
> On 18 Feb 2011, at 16:14, Reuti wrote:
>> The term "interactive" is more in a sense of "immediate". With "-now n",
>> resp. "-now y", you can run an interactive job in a batch only queue or a
>> batch job in an interactive only queue.
>>
>> For parallel jobs it's like an implied batch queue.
>>
>> The qtype in the queue definition will only be considered for interactive
>> jobs in this case. But even if qtype is set to NONE (or BATCH), you can run
>> a parallel interactive jobs by using "-now n" therein though.
>
> Hmm, I'm not quite sure what you mean. How come /serial/ batch jobs wait in
> the batch.q queue without being started on the interactive.q,
In this case qtype is checked - it's set to INTERACTIVE and so no /serial/
batch job will start there. This is what you observe.
> whereas by parallel (smp) jobs get scheduled to the interactive.q?
By attaching a PE to a queue, it will imply a batch behavior if this PE is
requested. It's not possible to setup an "interactive only" parallel-queue.
> Moreover, I can submit my job as a vanilla serial job and it waits in
> batch.q as expected. If I submit it as -pe smp 1, then it get scheduled to
> the interactive.q. Is this really expected behaviour?
The workaround could be to use JSV to route it to the correct queue, but this
is of course not a clean solution.
Maybe an RFE could be to remove the qtype setting in the queue configuration,
and instead offer such a setting in an RQS:
{
...
limit pes mpich qtypes batch to slots=0
}
where "qtypes" can have the values "batch" or "immediate" or the usual RQS
combination thereof (which would also remove the confusion about "what is
interactive").
-- Reuti
> Cheers,
>
> Chris
>
>
>
>
>
>
>
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
