LSF - Common FAQs
What is fairshare scheduling?
Fairshare scheduling is our way of making sure that every user in an LSF cluster gets his or her fair share of the CPU resources over time. If we used "first-come, first-served" scheduling instead, a user could submit 500 jobs at once and everybody else who submitted their jobs after that would have to wait until those 500 jobs had finished before their own jobs could run.
Each LSF user has a dynamic priority that is based on the number of shares assigned to that user (usually 1), the dynamic priority formula, and the amount of CPU time and run time used recently by all of that user's jobs. As you use more resources, your dynamic priority decreases. As your jobs finish, your dynamic priority increases. Note that CPU time used recently is weighted more heavily that CPU time used in the past.
The higher your dynamic priority, the more likely it is that your pending job will be the next one to be run by LSF.
How do I tell LSF to put my job output in a file instead of sending it to me by email?
You can redirect your job's standard output to a file using the “-o” option on the “bsub” command. When you do this, LSF appends to this file the job summary information you would normally receive in email after the completion of the job.
bsub -q queue -R resource -o out.%J executable
How many LSF jobs can I run at the same time?
Job limits in LSF are based on slots rather than jobs. A serial job uses one slot, while a four-way parallel job uses four slots.
When you are logged into Emerald, you can use up to 60 slots at once. You could run 60 serial jobs, one 56-way parallel job and four serial jobs or any combination of serial and parallel jobs as long as their total slots do not exceed 60. Of course some queues have slot limits for users. For example, the “month” queue will allow only four slots per user. The “patrons” queue limit varies by group and is equal to the number of slots the group has. The “idle” queue has no queue limits but jobs running in that queue may be preempted by “patrons” queue jobs.
If you log to Cedar, you can use 36 slots.
How can I access a larger temp directory space for jobs submitted with LSF?
Certain programs, such as SAS and Gaussian, may require a large working directory space (referred to as the temp directory) during the computation or analysis performed in a job. In some cases, the default temp space is not sufficient for exceptionally large jobs and will lead to errors due to lack of hard drive space. Therefore, resources have been developed that will allow for the specification of a larger temp directory space by use of the “-R” option in the “bsub” command. For example, to submit a Gaussian job specifying 10G (i.e. 10 gigabytes) of temp directory space, you would use the following command:
bsub -q week -R tmp10G -o out.%J g03 test.com
To submit a SAS job specifying a 10G temp directory space, the following command would be used:
bsub -q week -R tmp10G sas myprog.sas
However, when submitting a SAS job specifying 100G of temp directory space, you need to specify the location of the temp directory space, which is /saswork, so the command would be:
bsub -R tmp100G sas -work /saswork my_prog.sas
The resources tmp25G, tmp30G, tmp60G, tmp100G and tmp500G can be specified to provide 25 gigabyte, 30 gigabyte, 60 gigabyte, 100 gigabyte and 500 gigabyte temp directory spaces, respectively.
Additional help
Document Overview
Tags: FAQ , LSF , Load Sharing Facility , research computing servicesSubjects: Advanced Computing
Audience: Everyone
This work is licensed under a Creative Commons Attribution 3.0 United States License.
