On May 19, 2011, at 3:57 PM, Erik Erlandson wrote: > On Thu, 2011-05-19 at 15:29 -0500, Brian Bockelman wrote: > > >> Yup - that's what I had diagnosed too - but isn't this incorrect or at least counter-intuitive? > > I agree that there is a discontinuity as you describe, and it may be counter-intuitive. On the other hand, I'm unaware of a saner logic for mixing static and dynamic quotas. > > Static quotas are by definition requests for *exactly* some number of slots. So, the only way to make that happen is to allocate those exact amounts first. That leaves the remainder to be shared among dynamic quotas. So, as your number of slots decreases the amount shared among dynamic-quota groups by necessity grows smaller, until at some point it hits zero. > > Now, consider the logic for sharing surplus quotas. The fair way to do that is in proportion to the quotas assigned above. If you're got some groups with non-zero quota, and some groups with zero quota, the explainable way I came up with for that was to first share proportionally among all non-zero quotas, and if there is any remaining surplus after that, then zero-quota groups can share the remainder equally. > > I cannot access red-condor.unl.edu -- If you can email me your hierarchical acct group config, I can think about an approach to addressing your goals. At the moment your use case for mixed static/dynamic still isn't clear to me. Hi Erik, I wanted to give you more background on our use case. We have basically five categories of users: 1) CMS users from Nebraska (a strict subset of 2). 100 additional guaranteed slots. 2) CMS users from the US (a strict subset of 3). No additional guaranteed slots. 3) CMS users. 500 slots. 4) CMS production. 500 slots. 5) Everyone else. 10% of the cluster. When there is surplus (and there is, as the cluster is about 2000 cores), we want it allocated in priority order. I.e., a slot should go to a Nebraska user before a US user, a US user before a generic CMS user, etc. The only way I could figure out how to implement this was with mixing static and dynamic groups, as the static group will stay the same and the dynamic group will expand. Even this is an approximation because I don't think I have handled the USCMS-as-a-subset-of-CMS situation handled correctly. I've been thinking lately that maybe there's something clever possible by assigning jobs to non-leaf nodes in the hierarchy, but haven't been able to solve it. Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature