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. The naive approach for allocating surplus would be: 1) Allocate static groups until they hit their original limits or run out of requests. 2) Allocate dynamic groups the remainder or until they run out of requests. 3) Allocate the remainder to static groups until they run out of requests Is there anything wrong with that approach? It seems strange to handle static/dynamic separately in the initial allocation, then handle them as if they were identical in the surplus allocation. > > 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. Actually, we were able to avoid it by removing unnecessary groups, making the "top level" sufficiently large. So, problem avoided for now. Brian FWIW - I can access red-condor.unl.edu from my home cable modem... maybe a firewall on your side? brian-bockelmans-macbook-pro-3:~ brian$ condor_config_val -pool red-condor.unl.edu -name red-condor.unl.edu GROUP_NAMES cms, cms.prod, cms.lcgadmin, cms.other, cms.other.prio, cms.other.user, cms.other.user.nonus, cms.other.user.us, cms.other.user.t3, other, other.hcc > E > > > > _______________________________________________ > Condor-devel mailing list > Condor-devel@xxxxxxxxxxx > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature