[GE users] Advance reservations limited to s_rt=20:20:0 ?

reuti reuti at staff.uni-marburg.de
Wed Oct 27 08:05:34 BST 2010


Hi,

Am 22.10.2010 um 01:27 schrieb kisielk <kamil at kamilkisiel.net>:

> I'm seeing some weird behavior with advance reservations and  
> limiting the walltime for jobs. See the output of the commands below:
>
> umeshu:~ kamil$  qrsub -l s_rt=100:0:0 -d 500:0:0
> Your advance reservation 58 has been granted
>
> umeshu:~ kamil$  qrsh -now no -ar 58 -l s_rt=100:0:0 -w v
> Job 332508 cannot run in queue instance "maintenance.q" because it  
> was not reserved by advance reservation 58
> Job 332508 cannot run in queue instance "interactive.q" because it  
> was not reserved by advance reservation 58
> Job 332508 (-l s_rt=360000) cannot run in queue "batch.q at node080.example.com 
> " because it offers only qf:s_rt=20:20:00
> verification: no suitable queues

yep, this is issue 3250; although the limit seems to be different for  
different persons and/or installations.

In addition there was recently a discussion about soft requests used  
by jobs inside an AR, that the option "-w v" will indicate "no  
suitable queues", while "-w n" submits the job w/o error message and  
it is executed despite the former error message.

-- Reuti


> umeshu:~ kamil$ qstat -q batch.q at node080.example.com -F
> queuename                      qtype resv/used/tot. load_avg  
> arch          states
> --- 
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> batch.q at node080.example.com BP    1/7/8          5.54     lx26-amd64
>        gc:high_io=400
>        hl:arch=lx26-amd64
>        hl:num_proc=8
>        hl:mem_total=23.530G
>        hl:swap_total=0.000
>        hl:virtual_total=23.530G
>        hl:load_avg=5.540000
>        hl:load_short=5.620000
>        hl:load_medium=5.540000
>        hl:load_long=5.350000
>        hl:mem_free=21.631G
>        hl:swap_free=0.000
>        hl:virtual_free=21.631G
>        hl:mem_used=1.899G
>        hl:swap_used=0.000
>        hl:virtual_used=1.899G
>        hl:cpu=70.800000
>        hl:m_topology=SCCCCSCCCC
>        hl:m_topology_inuse=SCCCCSCCCC
>        hl:m_socket=0
>        hl:m_core=0
>        hl:np_load_avg=0.692500
>        hl:np_load_short=0.702500
>        hl:np_load_medium=0.692500
>        hl:np_load_long=0.668750
>        hf:infiniband=1.000000
>        hc:gpu=0
>        hc:h_vmem=13.000G
>        hc:exclusive=1.000000
>        hf:tesla_s1070=1.000000
>        qf:qname=batch.q
>        qf:hostname=node080.example.com
>        qc:slots=1
>        qf:tmpdir=/tmp
>        qf:seq_no=1
>        qf:rerun=0.000000
>        qf:calendar=NONE
>        qf:s_rt=6:23:59:00
>        qf:h_rt=7:00:00:00
>        qf:s_cpu=infinity
>        qf:h_cpu=infinity
>        qf:s_fsize=infinity
>        qf:h_fsize=infinity
>        qf:s_data=infinity
>        qf:h_data=infinity
>        qf:s_stack=infinity
>        qf:h_stack=infinity
>        qf:s_core=infinity
>        qf:h_core=infinity
>        qf:s_rss=infinity
>        qf:h_rss=infinity
>        qf:s_vmem=infinity
>        qf:min_cpu_interval=00:05:00
>
> umeshu:~ kamil$  qrsh -now no -ar 58 -l s_rt=20:19:00 -w v
> node080:~ kamil$
>
> The same behavior happens when using qsub, I'm just using qrsh -now  
> no here for illustrative purposes. Where is the limit of 20:20:0  
> coming from?
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=288998
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

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

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



More information about the gridengine-users mailing list