The accounting groups and user priorities control different steps of the allocation process. The groups do not have priorities and will always receive their requested allocation up to their GROUP_QUOTA. If you have GROUP_ACCEPT_SURPLUS = True,Â any leftover allocation is re-distributed proportionally to the original quotas. It does this first among sub-groups and then moves up the hierarchy. This lets a group potentially be allocated more than it's quota if other groups are not using theirs. It can be set per-group, so you can hard-cap any groups at their quotas if needed.Â
If you have any users/submitters that don't belong to a group, they get assigned to the base level '<none>' group.
After all of the groups have received an allocation they are ordered by GROUP_SORT_EXPR. The default 'starvation' ordering puts groups using the smallest percentage of their quota first, and the <none> group last.
As it iterates over through the groups it negotiates with each submitter/user in the current group ordered by their priority (lower first). That user receives a portion of their group's allocation proportional to their priority, with smaller priorities receiving more of the group's allocation. If you only have one user in a group this step is very simple, because that user will get the group's entire allocation and their user priority will be irrelevant.
So how is the user priority calculated?
The priority reported by condor_userprio is the Effective Priority, which is just the Real User Priority * Priority Factor. The default priority factor is 1000, and is a constant that can be set for each user. The Real User Priority (RUP) starts at 0.5 and halves the distance between it's current value and that user's current resource usage every PRIORITY_HALFLIFE seconds (set on the CM). If they are not using any resources for long enough, they will end up at 0.5 again.
If you want certain users to get a larger share of their group's allocation you should lower those users' priority factors. For example, a user with a priority factor of 500 will be able to use twice the resources of a user with the default factor of 1000. This isn't a hard cap, it just means these two priorities will equalize at that point.Â
GROUP_AUTOREGROUP makes things more complicated because the second time it negotiates with the submitters they're all in the <none> group. Having them all in one group means their priority is now affecting the resource distribution between groups. I'll assume you have this disabled for now (set to False).
Hopefully this helps,