[GE users] SGE6.0u3 global consumable resource - applies to all queues

Walt Minkel wminkel at latticesemi.com
Wed Feb 2 01:36:33 GMT 2005


Hi Reuti,

Thank you for deepening my understanding of the global consumables.

Your description of what I am trying to do is correct.  To fine tune my 
need,
I should add:   In addition to licenses being consumed for different 
tools, in one
tool's case, we have world wide WAN licenses as well as site licenses. 
 My goal was
to use queue sequencing to look first at the site license.  For example, 
A user could queue
in to "run_licA" without needing to specify a the consumable license 
"licA_us".

Suggestions are welcome but based on your comments, I think I will look for
any available license (site+WAN)  and have my execution script sort out 
which
to use.

     -Walt

Reuti wrote:

>Hi there,
>
>what you observe is the correct behavior of SGE. The complex "licA_us" isn't 
>requestable, and so it is attached to all jobs you submit to SGE. You have two 
>in total, so you can only run two jobs in the whole cluster of all type of 
>jobs. Where is the connection between "licA_us" and "run_licA" for now?
>
>If I understand you in the right way, you want one the one hand a limit global 
>which is two, and specify at the same time the nodes, on which this type of job 
>may run at all.
>
>You can achieve this when you make the complex requestable, then the user can 
>request it for this type of job. But with the current setup of a second complex 
>"run_licA", you would have to request both resourcesto get the desired 
>behavior.
>
>1. way)
>
>It's easier, when you disregard "run_licA" completely, and attach the "licA_us" 
>also to the nodes on which the jobs may run, set to the number of CPUs in this 
>machines. The request of the job has to fulfill both restrictions.
>
>2. way)
>
>Make one cluster queue for this type of job and setup a hostgroup with the 
>eligible machines. For this queue set "licA_us" to the number of CPUs, and in 
>all other queues set it to 0. Also here, no "run_licA" is needed.
>
>In both cases, the user has to specify only the request of the resource 
>"licA_us".
>
>Cheers - Reuti
>
>Quoting Walt Minkel <wminkel at latticesemi.com>:
>
>  
>
>>Hi All,
>>
>>I am trying to use global consumable resources to manage a variety of 
>>licenses using
>>SGE6.0u3.  I'm not seeing the behavior I expect...  As soon as I modify 
>>the global execution
>> host consumable form in qmon, every queue in my  grid is forced to find 
>>that resource
>>available before a job is run.  In some cases  I only have  two 
>>licenses.  Defining a global
>>resource for these two licenses, limits the total  number of jobs 
>>capable of running at one
>>time to two for the entire grid.
>>
>>My complex looks like this:
>>#name               shortcut          type        relop requestable 
>>consumable default  urgenc
>>lic_bv_us           licA_us         INT         <=         NO           
>> YES           1         0
>>
>>I am using the following to execute my script:
>>
>>qsub  -l  run_licA=1 myScript.csh                 run_licA is a complex 
>>I use to direct where the job can
>>                                                                       
>>   run.
>>
>>Queuing more than  two jobs (total for all queues), the pending jobs 
>>show this message:
>>
>>        (-l run_licA)  cannot run globally because for default request 
>>it offers only gc:licA_us=0.0000
>>
>>Maybe I'm missing something, or my approach is wrong.  Any suggestions 
>>would be greatly
>>appreciated.
>>
>>Thanks,
>>  Walt
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
>
>  
>




More information about the gridengine-users mailing list