This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
quick:walltime [2021/03/26 16:00] agill |
quick:walltime [2021/12/09 16:42] (current) |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| As most CHPC users will know, there is a limit on how long a job submitted to any queue on Lengau will be allowed to run for, as is specified in the user policy document. | As most CHPC users will know, there is a limit on how long a job submitted to any queue on Lengau will be allowed to run for, as is specified in the user policy document. | ||
| For instance, at present, jobs submitted to the normal queue cannot run for more than 48 hours. | For instance, at present, jobs submitted to the normal queue cannot run for more than 48 hours. | ||
| + | In your script, you'd specify it something like this: | ||
| - | It might be tempting, therefore, to specify this for the maximum allowed walltime for the queue, and not worry about how long the job will actually run for. However, this is not actually a good idea. | + | |
| + | |||
| + | It might be tempting, therefore, to specify this for the maximum allowed walltime for the queue, and not worry about how long the job will actually run for. However, this is not actually a good idea and may waste your time by delaying the start of your jobs. | ||
| When you submit a job using qsub, it gets passed to a piece of cluster-management software called the job-scheduler (we use PBS-Pro on lengau at present). This software looks at the requested walltime, cores, nodes and other resources requested for each job, and attempts to fit as many jobs into the available resources on the cluster as soon as is reasonable, so that no one job has too long a wait. In effect, you might say that it is a bit like playing tetris with the jobs. | When you submit a job using qsub, it gets passed to a piece of cluster-management software called the job-scheduler (we use PBS-Pro on lengau at present). This software looks at the requested walltime, cores, nodes and other resources requested for each job, and attempts to fit as many jobs into the available resources on the cluster as soon as is reasonable, so that no one job has too long a wait. In effect, you might say that it is a bit like playing tetris with the jobs. | ||