Here is what is confusing me I guess. Look at the below. You can see that some people have no usage and some people have a lot of usage. But their FairShare value is all identical.
https://lists.schedmd.com/mailman3/hyperkitty/list/slurm-users@lists.schedmd.com/thread/I53OEJSNBT2BMXYVFEFHQQKKAHIUYA53/ seems to say that fairshare=parent should work just fine, but what I am seeing is that it is NOT altering people's FairShare? $ sshare -l -a Account User RawShares NormShares RawUsage NormUsage EffectvUsage FairShare LevelFS GrpTRESMins TRESRunMins -------------------- ---------- ---------- ----------- ----------- ----------- ------------- ---------- ---------- ------------------------------ ------------------------------ root 0.000000 62159156 0.000000 cpu=170602,mem=1397577591,ene+ root root 1 0.008264 0 0.000000 0.000000 1.000000 inf cpu=0,mem=0,energy=0,node=0,b+ mic 120 0.991736 62159156 1.000000 1.000000 0.991736 cpu=170602,mem=1397577591,ene+ mic aamedina parent 0.991736 2376285 0.038230 0.038230 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic aaruldass parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic acataldo parent 0.991736 13066208 0.210193 0.210193 0.983871 cpu=169648,mem=1389757781,ene+ mic achowdhury parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ajajoo parent 0.991736 2074727 0.033378 0.033378 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ajanes parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic amandacao parent 0.991736 202 0.000003 0.000003 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic aromer parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic aweerasek+ parent 0.991736 1059 0.000017 0.000017 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic batwood parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic bleng parent 0.991736 3 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic cdemirlek parent 0.991736 6174 0.000099 0.000099 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic chun parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ckorponay parent 0.991736 1 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ddickstein parent 0.991736 116395 0.001873 0.001873 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ddillon parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ddrucker parent 0.991736 2033 0.000033 0.000033 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic dlombardo+ parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ebelleau parent 0.991736 1287758 0.020717 0.020717 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic ejoncas parent 0.991736 26064 0.000419 0.000419 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic eozan parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic epalermo parent 0.991736 202905 0.003264 0.003264 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic epayne parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic epcrabtree parent 0.991736 1 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic fdu parent 0.991736 1137902 0.018307 0.018307 0.983871 cpu=954,mem=7819810,energy=0,+ mic frederic parent 0.991736 1750024 0.028154 0.028154 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic hleblanc parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic itreves parent 0.991736 11 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic itsatsani parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic jcohen parent 0.991736 2 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic jpurcell parent 0.991736 2575695 0.041438 0.041438 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic jsneider parent 0.991736 1 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic kclancy parent 0.991736 595813 0.009585 0.009585 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic kjavaras parent 0.991736 17442 0.000281 0.000281 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic kohashi parent 0.991736 14883 0.000239 0.000239 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic kwebb parent 0.991736 2583 0.000042 0.000042 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic lfleming parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic lhutson parent 0.991736 4248 0.000068 0.000068 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic lnickerson parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic mhalko parent 0.991736 22566 0.000363 0.000363 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic mkuhn parent 0.991736 144709 0.002328 0.002328 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic mmaya parent 0.991736 122603 0.001972 0.001972 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic mrohan parent 0.991736 20309 0.000327 0.000327 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic mthai parent 0.991736 116 0.000002 0.000002 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic nharnett parent 0.991736 59 0.000001 0.000001 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic pkumar parent 0.991736 3330070 0.053574 0.053574 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic pzhukovsky parent 0.991736 310446 0.004994 0.004994 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic qdevignes parent 0.991736 1 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic rbgeary parent 0.991736 216108 0.003477 0.003477 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic rdanyogev parent 0.991736 437267 0.007035 0.007035 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic rvangool parent 0.991736 0 0.000000 0.000000 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic saslan parent 0.991736 31244545 0.502662 0.502662 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic sassili parent 0.991736 58935 0.000948 0.000948 0.983871 cpu=0,mem=0,energy=0,node=0,b+ mic sgranger parent 0.991736 195080 0.003138 0.003138 0.983871 cpu=0,mem=0,energy=0,node=0,b+ On Aug 10, 2024, at 7:24 AM, Drucker, Daniel <ddruc...@mclean.harvard.edu> wrote: So I'm still getting identical priorities for every job. For example in: squeue --format="%.18i %.9P %.50j %.8u %.8T %.10M %.9l %.6D %R %.10Q" the PRIORITY field is 98387 (which is 10000* the fairshare value shown in "sshare -a -A mic") for every single job, even though some of the jobs in the queue were submitted by users who have NEVER submitted a job before, and some of the jobs are users who have been submitting thousands of jobs a day every day for weeks. This seems ... unfair? On Aug 9, 2024, at 9:52 PM, Drucker, Daniel <ddruc...@mclean.harvard.edu> wrote: On Aug 9, 2024, at 9:21 PM, Fulcomer, Samuel <samuel_fulco...@brown.edu> wrote: And note that the high PriorityWeightAge may be complicating things. We set it to 0. With it set so high, it allows users to gain priority by flooding the queue if you allow high numbers of job submissions and they age up in priority while they're waiting to run. That's a great point. Changed to 0. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.
-- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
