HiÂAlessandra,
The groups themselves do not really have priority factors, they simply have a default value that is used by new users submitting to that group for the first time. I'm not sure why your condor_userprio output is even displaying values for them in the 'Priority Factor' column. It's blank for our output, which would more accurately represent things:
% condor_userprio -allusersÂ-hierarchical
Group                        Config  ÂUse  Effective ÂPriority ÂRes ÂTotal Usage Time Since RequestedÂ
 User Name                     ÂQuota ÂSurplus ÂPriority  Factor ÂIn Use (wghted-hrs) Last Usage ResourcesÂ
--------------------------------------------------- --------- ------- ------------ --------- ------ ------------ ---------- ----------
prod                          Â0.95 Regroup              Â0    Â0.00 17770+20:4     0
prod.btr                        Â0.00 Regroup              Â0    Â0.00 17770+20:4     0
prod.btr.btr_anim                    6.00 Regroup              Â0    40.76  3+00:14     0
 user@xxxxxxxxxxxxxxxxxxx                         500.00 Â1000.00   0    40.76  3+00:14     Â
Note that only the actual user in the group has a priority factor.
This is important because it means changing the defaults for new users in the config files has no effect on existing users in that group (even with a reconfig/restart). You can still change the priority factor for existing users with condor_userprio -setfactor <user> <val>. That said, I think the effective priority the factor contributes to is being used differently than you think.
When a new negotiation cycle starts it will use theÂGROUP_SORT_EXPR to decide on the order it will consider groups in. Since you have that defined to a non-default value in 11_fairshares it looks like your pool will always considerÂgroup_atlas.admin,Âgroup_northgrid.manchester, andÂgroup_skatelescope first, followed by any group with "multicore" in it's name in starvation order, then any other group in starvation order, and finally any user not in a group. During negotiation with any of these schedds it will order the users in the group using their effective priorities. The group ordering happens first and is therefore more important. During this round of negotiation, because you haveÂGROUP_ACCEPT_SURPLUS = true, any surplus allocation from a group is redistributed according to your group hierarchy.
In the same file you also haveÂGROUP_AUTOREGROUP = true, which complicates things a little more. Because of this, after each round of negotiating every group it will do a 'Regroup' negotiation round. During this 'Regroup' round it will negotiate every user a second time outside of their group, strictly ordered by their effective priority. After the regroup round it repeats the whole process a number of times determined by GROUP_QUOTA_MAX_ALLOCATION_ROUNDS. In my experience the subsequent rounds matter much less when AUTOREGROUP is enabled, because it tends to schedule almost all of the remaining resources during the 'Regroup' round if able. This round is why the different group priority factors matter to you, as they are loosely enforcing your group ordering when jobs are being considered outside of their groups.
I would suggest tryingÂGROUP_AUTOREGROUP = false, and instead adding a more specific ordering to GROUP_SORT_EXPR. This would make it easier to change the ordering in the future, and you could then largely ignore the group priority factors.
Hope this helps,
Collin
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}