[GE users] contemporary of -l slots=#

Marconnet, James E Mr /Computer Sciences Corporation james.marconnet at smdc.army.mil
Thu Mar 31 17:41:02 BST 2005


Stephan & Raphael:

You gave me the clue I needed to understand why I could not do what I was
trying. I was trying to double-click and then type in the attribute name. No
can do. Instead I must click on the button labeled "name" above and then
select from the pull-down list. Understanding that, I bet I'll find lots of
those subtle buttons that I had not noticed before.

Thanks Stephan and Raphael for straightening me out on this one.

Jim Marconnet 

-----Original Message-----
From: Stephan Grell - Sun Germany - SSG - Software Engineer
[mailto:stephan.grell at sun.com] 
Sent: Thursday, March 31, 2005 2:50 AM
To: users at gridengine.sunsource.net
Subject: Re: [GE users] contemporary of -l slots=#

Hello,

I assume, that you want to assign a complex attribute to an object (queue,
host, global)?

You have to press the Load button, which is right above the list with
assigned complex attributes. A window appears, which shows all available
complex attributes.

Cheers,
Stephan

Marconnet, James E Mr /Computer Sciences Corporation wrote:

>Is there a trick to setting up complex variables using qmon in 6.0u3?
>
>When I've tried to create one using qmon, I cannot get the cursor to 
>appear in the first part of the block where the name of the new 
>variable would be - I can only get the cursor to appear in the place 
>where the value goes by double-clicking there. Double-clicking in the left
block does nothing.
>
>Thanks!
>Jim Marconnet
>
>-----Original Message-----
>From: Reuti [mailto:reuti at staff.uni-marburg.de]
>Sent: Wednesday, March 30, 2005 1:54 PM
>To: users at gridengine.sunsource.net
>Subject: Re: [GE users] contemporary of -l slots=#
>
>Hi Raphael,
>
>it's personal taste, but I wouldn't use any of the two options you 
>offered - both are not refelecting the logic behind. Although: what I 
>suggest is similar to the second:
>
>- make the complex "virtual_free" consumable and requestable - default 1GB
>                                                       (or what you 
>like)
>
>- attach this to each node with a value of the built in memory
>                                    (complex_values   virtual_free=3.5GB)
>
>- request 3.5GB in your qsub command -> single job on the node
>
>
>With 4GB built in only 3.5GB are usable I think. Yes, it's nearly the 
>same as your vslots, but this can also be used for a real request of 
>just 2GB for larger jobs.
>
>Cheers - Reuti
>
>PS: IMO it's good to disallow the request for slots, to remind users to 
>request a PE - maybe they forgot it by accident.
>
>
>Quoting "Raphael Y. Rubin" <rafi at cs.caltech.edu>:
>
>  
>
>>I would like to configure my grid so that mortal users can grab 
>>exclusive access to a machine, using the normal submittion commands 
>>with little
>>    
>>
>extra
>  
>
>>work.
>>
>>Occassionally, a user wants to run a job exclusively for benchmarking, 
>>whether that's to test a class of machine or a specific job.
>>
>>Also some jobs we know will be resource hogs, and we'd like to 
>>annotate
>>    
>>
>them
>  
>
>>to indicate they are the equivalent of two or more normal jobs.
>>
>>And of course there are various other nees that arrise, but the above 
>>two
>>    
>>
>are
>  
>
>>the most common and important.  In the past we just use to specify "-l 
>>slots=n".  But as of sge5.3 that was discouraged.
>>
>>	error: denied: use parallel environments instead of requesting slots

>>explicitly
>>	
>>		- from sge6
>>
>>In sge 5.3, I had created a slots pe, after we first noticed the 
>>messages about -l slots.  Here is an updated version of that pe (in a 
>>form for sge 6).
>>
>>pe_name           slots
>>slots             999
>>user_lists        NONE
>>xuser_lists       NONE
>>start_proc_args   /bin/true
>>stop_proc_args    /bin/true
>>allocation_rule   $pe_slots
>>control_slaves    FALSE
>>job_is_first_task TRUE
>>urgency_slots     min
>>
>>Alternatively, one can use a consumable complex, as described  in:
>>
>>    
>>
>http://gridengine.sunsource.net/servlets/BrowseList?list=users&by=threa
>d&fro
>m=2
>530
>  
>
>>or more simply:
>>#name               shortcut   type        relop requestable consumable 
>>default  urgency
>>
>>    
>>
>#----------------------------------------------------------------------
>-----
>---
>----------
>  
>
>>vslots              vs         INT         <=    YES         YES        1
>>1000
>>
>>Which is of course just the normal complex slots copied to a different 
>>name to get around the explicit "-l slots" block.  Somehow this seems 
>>wrong, a reincarnation of a technique deliberately killed for some 
>>reason unknown to me.
>>
>>
>>
>>Which style is prefered and why?
>>What are the ramifications?
>>Are there any behavioral differences?
>>
>>
>>As for the prefered option, any suggestions to improve the above 
>>configurations?
>>Also what's the best way to deploy, either globally, or to a set of
>>    
>>
>queues?
>  
>
>>I know with sge 5.3, I was able to use:
>>queue_list        all
>>To deploy to my whole cell.
>>
>>
>>
>>Also on a not complete tangent.  Does anyone have advice, or has 
>>anyone written guidelines to optimize configuration of queues?  We are 
>>mostly using dual cpu xeons with hyperthreading and 4G of ram.
>>
>>Our jobs are mostly java, c, and lisp, single threaded (except the jvm 
>>which forks its own stuff).  Jobs mostly run in a few hundred MB or 
>>less, with a occasional memory hog which will eat a gig or two.
>>
>>
>>Rafi Rubin
>>California Institute of Technology
>>
>>---------------------------------------------------------------------
>>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
>
>---------------------------------------------------------------------
>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

---------------------------------------------------------------------
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