[GE users] Overriding a default value with no value?

futuritymmx neil.baker at crl.toshiba.co.uk
Thu May 21 14:18:42 BST 2009


Hi Chris,

The -clear option works :)

We have a lot of legacy scripts used for jobs that haven't been tested
against 64bit yet.  They include submitting scripts that have simple qsub
commands embedded in them (I didn't write them) and I'm told that these will
be difficult to modify.

Therefore, when we introduced 64bit machines into our grid, we wanted the
default behaviour to be to run jobs on 32bit machines.  If users wanted
64bit, then had to specify it in their qsub command to replace the 32bit
requirement.

However, we now how users that have jobs that can run on either, hence the
need to unset / clear the 32bit default request.

Your -clear parameter does the trick allowing users to submit jobs
specifying the job options from scratch.

Strange that the -soft option doesn't work.  Would have been an easier
solution, allow users to replace just the one requirement rather than having
to specify the long lit again, but at least the -clear works :)

Many thanks for your help.

Neil

-----Original Message-----
From: craffi [mailto:dag at sonsorol.org] 
Sent: 21 May 2009 14:00
To: users at gridengine.sunsource.net
Subject: Re: [GE users] Overriding a default value with no value?

A few thoughts come to mind ...

(1) Test with "qsub -clear ... " to blow away any other default  
settings that may be messing you up

(2) Set "sched_job_info=true" in your SGE config so that "qstat -j  
<jobID>" on the pending jobs shows you exactly why they are not being  
dispatched

(3) Why make an arch request at all if you don't care where the jobs  
run? Are their other systems in the cluster?

-Chris



On May 21, 2009, at 8:54 AM, futuritymmx wrote:

> Although my problem is described correctly, I've accidentally pasted  
> the
> wrong architecture into my previous email.  To clarify my problem:
>
> When I submit jobs specifying the 64bit architecture, they run on  
> only the
> 64bit architecture machines:
>
> qsub -l arch=lx24-amd64 /rmt/home/nbaker/gridenginetests/a60.sh
>
> However, when I add "-soft" my jobs only run on 32bit machines, even  
> though
> I have more jobs submitted than 32bit machines to run them on.
>
> qsub -soft -l arch=lx24-amd64 /rmt/home/nbaker/gridenginetests/a60.sh
>
> They are queued rather than run on the 64bit machines.  Surely there  
> should
> be a preference for 64bit machines.  Jobs should try to run there  
> first,
> then only run on 32bit machines when all the 64bit slots have been  
> filled?
>
> Please note that in sge_request the default arch request is for 32bit
> machines i.e. arch=lx24-x86 (see previous email below but one).
>
> Neil
>
> -----Original Message-----
> From: Neil Baker [mailto:neil.baker at crl.toshiba.co.uk]
> Sent: 21 May 2009 13:41
> To: 'users'
> Subject: RE: [GE users] Overriding a default value with no value?
>
> Could it be that because there is a hard requirement in sge_request  
> for a
> 32bit architecture, that this is why the soft requirement for 64bit
> architecture is ignored and therefore why jobs are only run on 32bit
> machines?
>
> If this is the case, then it looks like the -soft option can't be  
> used to
> cancel a requirement that is defined in sge_request.
>
> Have I used the -soft option incorrectly, or is there another way I  
> can
> cancel a default value defined in sge_request?
>
> Neil
>
> -----Original Message-----
> From: Neil Baker [mailto:neil.baker at crl.toshiba.co.uk]
> Sent: 21 May 2009 13:16
> To: 'users'
> Subject: RE: [GE users] Overriding a default value with no value?
>
> Hmmm I'm getting very strange behaviour using "-soft".
>
> Using "qsub -l arch=lx24-x86", jobs only run on 64 bit machines.
>
> Using "qsub -soft -l arch=lx24-x86", jobs only run on 32bit  
> machines, but no
> 64bit machines.  I'd expect then to run on both architectures.  The  
> queue
> was flooded in both tests with over 100 jobs still waiting to be  
> queued.
>
> Current default values in sge_request are:
>
> -p -100 -S /bin/bash -cwd -l qp=low,vf=256M,arch=lx24-x86
>
> "qp" is our "qname" which is a requestable value used for selecting  
> one of
> our virtual queues (made up on many queues).
>
> "vf" is used to specify how much virtual memory each job will require.
>
> "arch" is the architecture.
>
> So by using "-soft" in the above qsub command, why does is switch to  
> only
> using 32bit machines when in theory it should not care and allow  
> jobs to run
> them on any architecture / machine?
>
> Neil
>
> -----Original Message-----
> From: adary [mailto:adary at marvell.com]
> Sent: 21 May 2009 12:19
> To: users at gridengine.sunsource.net
> Subject: RE: [GE users] Overriding a default value with no value?
>
> qsub -soft -l arch-lx24-x86 .....
>
> this is more or less: try x86, if its not available use any other arch
>
> -----Original Message-----
> From: futurity [mailto:neil at futurity.co.uk]
> Sent: Thursday, May 21, 2009 2:09 PM
> To: users at gridengine.sunsource.net
> Subject: [GE users] Overriding a default value with no value?
>
> Hi Fellow Grid Users,
>
> We have a grid with one queue that contains both 32bit and 64bit  
> execution
> hosts.
>
> By default when users use qsub it defaults to "arch=lx24-x86" as  
> defined in
> the file:
>
> $SGE_ROOT/default/common/sge_request
>
> When users want to use 64bit machines they use "arch=lx24-amd64".
>
> However what do I need to use to allow my jobs to run on any machine  
> (i.e. I
> on 32bit and 64bit machines)?
>
> If I submit jobs with "arch="  as in setting it to no value I  
> receive the
> following message:
>
> Submitting Job Number 1...
> Unable to run job: denied: missing value for request "arch".
> Exiting.
>
> We don't want 95% our users to have to specify 32bit machines in their
> scripts because it would be a lot of work for them to do so.
>
> Any ideas how I solve this problem?
>
> Neil
>
> ------------------------------------------------------
>
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=1
> 97990
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe at gridengine.sunsource.net].
>
> ------------------------------------------------------
>
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=1
> 97992
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe at gridengine.sunsource.net].
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ------------------------------------------------------
>
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=1
98017
>
> To unsubscribe from this discussion, e-mail:
[users-unsubscribe at gridengine.sunsource.net 
> ].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=1
98019

To unsubscribe from this discussion, e-mail:
[users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=198024

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list