User Tools

Site Tools



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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
runtime [2015/12/03 17:15]
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>​ 
 +or within ​script 
 +<code bash> 
 +#SBATCH -t <time reservation>​ 
 +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 ... 
 +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://​​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: 2019/11/15 16:30 by jrutte02