User Tools

Site Tools


runtime

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
runtime [2017/06/09 09:38]
meesters removed
runtime [2017/06/09 09:53]
meesters created
Line 1: Line 1:
-====== Runtime ​Normalization ​======+====== ​Specifying ​Runtime ======
  
-As measure to fairness schedulers ​are aware of different CPU-factors for different execution hosts to accommodate for the different execution speedsAs result wall clock times are different for the different execution hosts.+Requesting runtime is straightforward:​ The ''​-t''​ or ''​--time''​ flag can be used in ''​srun''/''​salloc''​ and ''​sbatch'' ​ alike: 
 + 
 +<code bash> 
 +$ srun --time <time reservation>​ 
 +</​code>​ 
 + 
 +or within ​script 
 +<code bash> 
 +#SBATCH -t <time reservation>​ 
 +</​code>​ 
 +where ''<​time reservation>''​ can be any of the acceptable time formats ''​minutes'',​ ''​minutes:​seconds'',​ ''​hours:​minutes:​seconds'',​ ''​days-hours'',​ ''​days-hours:​minutes''​ and ''​days-hours:​minutes:​seconds''​.  
 + 
 +Time resolution is one minute and second values ​are rounded up to the next minute. A time limit of zero requests that no time limit be imposed, meaning that the maximum runtime of the [[queues|partition]] will be used. 
 + 
 +===== Signals ===== 
 + 
 +Slurm does not send signals if not requested. You can request a specific signal with ''​--signal''​ either ​to ''​srun''​ or ''​sbatch''​ from within a script. The flag can be used like ''​--signal=<​sig_num>​[@<​sig_time>​]'':​ When a job is within ''​sig_time''​ seconds of its end time,  then the signal ''​sig_num''​ is sendedIf sig_num is specified without any sig_time, ​the default time will 60 seconds. Due to the resolution of event handling by Slurm, the signal may be sent up to 60 seconds earlier than specified. 
 + 
 +An example would be 
 + 
 +<code bash> 
 +$ sbatch --signal=SIGUSR2@600 ... 
 +</​code>​ 
 +here, the signal ''​SIGUSR2''​ is send to the application ten minutes before hitting the walltime of the job. Note once more that the slurm documentation states that there is a uncertainty of up to 1 minute.
  
-On MOGON no additional consideration has to be made upon submission to the "​standard hosts" (a0001-a0555) from the standard login nodes. 
  
-However, LSF requires a run time normalization,​ if the submission host's CPU factor differs from that of the execution host. For a detailed description the the [[https://​www-01.ibm.com/​support/​knowledgecenter/​SSETD4_9.1.2/​lsf_admin/​cpu_run_time_normalization.dita|LSF-Manual Entry]]. This is particularly important upon using [[lsf_gpu|GPU queues]]. 
  
-A simple solution to such problems is: A reference host for each queue is known and can be retrieved with ''​bqueues -l <​queuename>​ | grep ".0 min"''​. When submitting this hosts can be given as the reference: ''​bsub ... -W 120/<​reference host>'',​ here 120 minutes (real time) are given for the reference host. 
runtime.txt · Last modified: 2017/06/09 09:53 by meesters