Walltime Experiment
From UF HPC Wiki
Contents |
[edit] Experiment
Determine whether or not Maui is scheduling jobs with backfill.
[edit] Inputs
Single job which had the capability to use four processors in an SMP configuration. The job takes approximately one hour, forty minutes to complete.
Because the job is known to take this amount of time, every time, the amount of time to schedule was known, and two hours was selected to give some breathing room for the job.
The same job executable was used for both kinds of input.
Jobs were submitted with either a 2 hour walltime set, or no walltime set. With no walltime set, Maui defaults to what it considers to be an infinite amount of time, since it does not know how long to actually schedule the job for. This time setting was selected in order facilitate all users.
First, jobs were submitted such that the 2-hour job was first, then immediately following this job an infinite-walltime job was submitted. Predictably, the 2-hour job always ran first.
Next, the infinite-walltime jobs were submitted first, then immediately (within one second) the 2-hour job was submitted. The results from this were not as predictable. The following were the different ways in which the two kinds of jobs would start:
- Both jobs start at the same time. This may have been instantaneous or after a delay.
- The infinite job would start first, followed by the 2-hour job some amount of time afterwards.
- The 2-hour job would start first, followed by the infinite job some amount of time afterwards.
[edit] Results
Overall, with both kinds of job being started at the exact same time, the average wait time for a 2-hour walltime job was 11.8 hours, while the wait time for the infinite walltime job turned out to be 16 hours. While setting the 2-hour walltime did not necessarily take precedence over the order in which the jobs were submitted, overall it did make a difference.
[edit] Conclusion
It is best to set the walltime on a job if it is known or can be predicted. This aids the Maui system in scheduling of other jobs, as well as the job being submitted.
If a walltime is not known for a job, a prediction is the next best thing. If a walltime is getting close on a job, particularly an extended period job, and good data is being produced by that job, the walltime can be adjusted while the job is running, so long as the user takes care to monitor what is happening with the job. This can be done with the qalter command. Note that only the superuser can extend a walltime once the job is running. Once a runtime for a job is found and is predictable, the job will become much easier for Maui to schedule.
