On Wed, 2011-12-14 at 16:16 -0500, Edsall, William (WJ) wrote: > Unfortunately I had to clear them out to fit some jobs in.. but I have > a similar comparison: > > > ]# diagnose -p | more > diagnosing job priority information (partition: ALL) > > Job PRIORITY* Cred( QOS:Class) Serv(QTime) > Weights -------- 1( 1: 1) 1( 1) > > 258693 10076 1.0( 0.0:100.0) 99.0(9975.) > 258704 10076 1.0( 0.0:100.0) 99.0(9975.) > 258705 10076 1.0( 0.0:100.0) 99.0(9975.) > 258708 10076 1.0( 0.0:100.0) 99.0(9975.) > 258714 10076 1.0( 0.0:100.0) 99.0(9975.) > 258474 9949 1.0( 0.0:100.0) 99.0(9849.) > 258463 9810 1.0( 0.0:100.0) 99.0(9709.) > > These top jobs with 10,000+ are preempted, originally had 100 > priority. Currently they are suspended.
IIRC, the QUEUETIMEWEIGHT factor is multiplied by the number of minutes the job has been eligible to run, and the default value for it is 1. There are a couple different thing you could do here: * Set QUEUETIMEWEIGHT to 0, which has the potentially unfortunate side effect of not giving any priority to *any* jobs which have been sitting for a long time. * Set CREDWEIGHT to something larger than 1 (e.g. 10 or 100) to reduce the relative effect of jobs' queue wait time relative to the priority factor from the class. * Use a QOS to adjust QUEUETIMEWEIGHT for the jobs in question. (See http://www.adaptivecomputing.com/resources/docs/maui/5.1.2priorityfactors.php#queuetimesubcomponent for details.) --Troy -- Troy Baer, HPC System Administrator National Institute for Computational Sciences, University of Tennessee http://www.nics.tennessee.edu/ Phone: 865-241-4233 _______________________________________________ mauiusers mailing list [email protected] http://www.supercluster.org/mailman/listinfo/mauiusers
