KeyWords: queue downtime
Reducing queue closure time before scheduled downtimes
Right now we are closing the queues 2.5 days before scheduled downtimes. It turns out that this is too much.
There is a big difference between the required walltime specified in your VO cards and the time the jobs actually take to run.
In this table, we gathered the information specified in the VO cards, and the statistical information taken from the last 5 months. Only jobs longer than 1 hour are considered.
value |
lhcb |
atlas |
cms |
CPUTIME in VO card |
? |
37.3 |
19.7 |
max CPUTIME in queue |
32 |
48 |
24 |
PROPOSED CPUTIME in queue |
32 |
42 |
24 |
WALLTIME in VO card |
30.7 |
41.6 |
72 |
max WALLTIME defined in queue |
48 |
48 |
72 |
PROPOSED WALLTIME defined in queue |
32 |
42 |
72 |
max(avg,median) real job CPUTIME |
21.8 |
3.5 |
3.5 |
max(avg,median) real job WALLTIME |
25.8 |
4.9 |
5.5 |
95% of jobs finish below WALLTIME |
55 |
19 |
20 |
PROPOSED closure time before downtime |
55 |
20 |
20 |
(time specified in hours)
We should review the proposed closure time before downtime some time after changing the walltime defined in the lhcb queue, it will probably influence the statistics, since lhcb tried to use all the time it's given in the queue.
Also, please keep in mind that the walltime limit in the queue is the number that is published but it is relaxed. We give 6 additional hours of courtesy.
Readers' comments