Gerry, I'm going to throw an answer out, but it's mostly opinion and conjecture. However, it's how I have explained fairshare to my users and boss, so if it's wrong, don't tell them.
The goal of fairshare is to have high overall utilization and prevent a single user/group from using more resources than are "fair" over time. Note the very important "over time" in there. If a user is the only person submitting jobs, we want them to have 100% of the machine. As soon as a second user comes along, their fairshare should be higher than the first user and as the first users jobs complete then the second users jobs will start. If they both continue to submit jobs then over time we would expect both users utilization to be about 50% of the available resources. In short, fairshare isn't about what the machine is doing Right Now(tm) but more about what it has been doing over the previous period of time equal to the fairshare calculation window. The ways in which we mitigate the effects on Right Now(tm) are: - Reservations for specific projects to guarantee a minimum set of resources available. - A small interactive partition with limits on how much 1 person can use and short max walltime (relative to other resources.) - Repeating the explanation verbatim to the users who ask about this every time they are in a hurry to get a job running. I'd love to hear how other people address this in different environments. We are slowly migrating away from dividing things with partitions and toward using QoS and fairshare to control access. Examples of different approaches would be appreciated. Regards, jbh
