-
Notifications
You must be signed in to change notification settings - Fork 1
/
5.1.2priorityfactors.html
495 lines (322 loc) · 25.7 KB
/
5.1.2priorityfactors.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
<html>
<head>
<meta name="generator" content="HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<title></title>
</head>
<body>
<div class="sright">
<div class="sub-content-head">
Maui Scheduler
</div>
<div id="sub-content-rpt" class="sub-content-rpt">
<div class="tab-container docs" id="tab-container">
<div class="topNav">
<div class="docsSearch"></div>
<div class="navIcons topIcons">
<a href="index.html"><img src="home.png" title="Home" alt="Home" border="0"></a> <a href="5.1jobprioritization.html"><img src="upArrow.png" title="Up" alt="Up" border="0"></a> <a href="5.1.1priorityoverview.html"><img src="prevArrow.png" title="Previous" alt="Previous" border="0"></a> <a href="5.1.3priorityusage.html"><img src="nextArrow.png" title="Next" alt="Next" border="0"></a>
</div>
<h1>5.1.2 Job Priority Factors</h1>
<p>Maui allows jobs to be prioritized based on a range of job related factors. These factors are broken down into a two-level hierarchy of priority factors and subfactors each of which can be independently assigned a weight. This approach provides the administrator with detailed yet straightforward control of the job selection process. The table below highlights the components and subcomponents which make up the total job priority.</p>
<p><img src="logo1.gif" height="24"> With the <a href="http://docs.adaptivecomputing.com/mcm/index.html">Moab Cluster Manager</a><sup>TM</sup>, priority factors and subfactors can be controlled with sliding bars and the click of the mouse. Also, the calculated priority, broken up by factors and subfactors, is enumerated in a table to see their effects. (Click <a href="http://docs.adaptivecomputing.com/mcm/priority.html">HERE</a> for more information)<br></p>
<table border width="100%" nosave="">
<tr>
<td><b>Component</b></td>
<td><b>SubComponent</b></td>
<td><b>Metric</b></td>
</tr>
<tr>
<td><b>CRED</b><br>
(job credentials)</td>
<td>USER</td>
<td>user specific priority (See <a href="a.fparameters.html#usercfg">USERCFG</a>)</td>
</tr>
<tr>
<td></td>
<td>GROUP</td>
<td>group specific priority (See <a href="a.fparameters.html#groupcfg">GROUPCFG</a>)</td>
</tr>
<tr>
<td></td>
<td>ACCOUNT</td>
<td>account specific priority (SEE <a href="a.fparameters.html#accountcfg">ACCOUNTCFG</a>)</td>
</tr>
<tr>
<td></td>
<td>QOS</td>
<td>QOS specific priority (See <a href="a.fparameters.html#qoscfg">QOSCFG</a>)</td>
</tr>
<tr>
<td></td>
<td>CLASS</td>
<td>class/queue specific priority (See <a href="a.fparameters.html#classcfg">CLASSCFG</a>)</td>
</tr>
<tr>
<td><b>FS</b><br>
(fairshare usage)</td>
<td>FSUSER</td>
<td>user based historical usage (See <a href="6.3fairshare.html#overview">Fairshare Overview</a>)</td>
</tr>
<tr>
<td></td>
<td>FSGROUP</td>
<td>group based historical usage (See <a href="6.3fairshare.html#overview">Fairshare Overview</a>)</td>
</tr>
<tr>
<td></td>
<td>FSACCOUNT</td>
<td>account based historical usage (See <a href="6.3fairshare.html#overview">Fairshare Overview</a>)</td>
</tr>
<tr>
<td></td>
<td>FSQOS</td>
<td>QOS base historical usage (See <a href="6.3fairshare.html#overview">Fairshare Overview</a>)</td>
</tr>
<tr>
<td></td>
<td>FSCLASS</td>
<td>class/queue based historical usage (See <a href="6.3fairshare.html#overview">Fairshare Overview</a>)</td>
</tr>
<tr>
<td><b>RES</b><br>
(requested job resources)</td>
<td>NODE</td>
<td>number of nodes requested</td>
</tr>
<tr>
<td></td>
<td>PROC</td>
<td>number of processors requested</td>
</tr>
<tr>
<td></td>
<td>MEM</td>
<td>total real memory requested (in MB)</td>
</tr>
<tr>
<td></td>
<td>SWAP</td>
<td>total virtual memory requested (in MB)</td>
</tr>
<tr>
<td></td>
<td>DISK</td>
<td>total local disk requested (in MB)</td>
</tr>
<tr>
<td></td>
<td>PS</td>
<td>total proc-seconds requested</td>
</tr>
<tr>
<td></td>
<td>PE</td>
<td>total processor-equivalent requested</td>
</tr>
<tr>
<td></td>
<td>WALLTIME</td>
<td>total walltime requested (in seconds)</td>
</tr>
<tr>
<td><b>SERV</b><br>
(current service levels)</td>
<td>QUEUETIME</td>
<td>time job has been queued (in minutes)</td>
</tr>
<tr>
<td></td>
<td>XFACTOR</td>
<td>minimum job expansion factor</td>
</tr>
<tr>
<td></td>
<td>BYPASS</td>
<td>number of times job has been bypassed by backfill</td>
</tr>
<tr>
<td><b>TARGET</b><br>
(target service levels)</td>
<td>TARGETQUEUETIME</td>
<td>time until queuetime target is reached (exponential)</td>
</tr>
<tr>
<td></td>
<td>TARGETXFACTOR</td>
<td>distance to target expansion factor (exponential)</td>
</tr>
<tr>
<td><b>USAGE</b><br>
(consumed resources -- active jobs only)</td>
<td>CONSUMED</td>
<td>proc-seconds dedicated to date</td>
</tr>
<tr>
<td></td>
<td>REMAINING</td>
<td>proc-seconds outstanding</td>
</tr>
<tr>
<td></td>
<td>PERCENT</td>
<td>percent of required walltime consumed</td>
</tr>
<tr>
<td></td>
<td>EXECUTIONTIME</td>
<td>seconds since job started</td>
</tr>
</table>
<h2><a name="cred"></a>5.1.2.1 Credential (CRED) Component</h2>
<p>The credential component allows a site to prioritize jobs based on political issues such as the relative importance of certain groups or accounts. This allows direct political priorities to be applied to jobs.</p>
<p>The priority calculation for the credential component is:</p>
<p><tt>Priority += CREDWEIGHT * (</tt><br>
<tt>USERWEIGHT * J->U->Priority +</tt><br>
<tt>GROUPWEIGHT * J->G->Priority +</tt><br>
<tt>ACCOUNTWEIGHT * J->A->Priority +</tt><br>
<tt>QOSWEIGHT * J->Q->Priority +</tt><br>
<tt>CLASSWEIGHT * J->C->Priority)</tt></p>
<p>All user, group, account, QoS, and class weights are specified by setting the <b>PRIORITY</b> attribute of using the respective '<b>*CFG</b>' parameter, namely, <b>USERCFG</b>, <b>GROUPCFG</b>, <b>ACCOUNTCFG</b>, <b>QOSCFG</b>, and <b>CLASSCFG</b>.</p>
<p>For example, to set user and group priorities, the following might be used.</p>
<p>---<br>
<tt>CREDWEIGHT 1</tt><br>
<tt>USERWEIGHT 1</tt><br>
<tt>GROUPWEIGHT 1</tt></p>
<p><tt>USERCFG[john] PRIORITY=2000</tt><br>
<tt>USERCFG[paul] PRIORITY=-1000</tt></p>
<p><tt>GROUPCFG[staff] PRIORITY=10000</tt><br>
---</p>
<p><img src="note.png" height="24" width="20">Class (or queue) priority may also be specified via the resource manager where supported (i.e., PBS queue priorities). However, if Maui class priority values are also specified, the resource manager priority values will be overwritten.</p>
<p>All priorities may be positive or negative.</p>
<h2><a name="fairshare"></a>5.1.2.2 Fairshare (FS) Component</h2>
<p>Fairshare components allow a site to favor jobs based on short term historical usage. The Fairshare Overview describes the configuration and use of Fairshare in detail.</p>
<p>After the brief reprieve from complexity found in the QOS factor, we come to the Fairshare factor. This factor is used to adjust a job's priority based on the historical percentage system utilization of the jobs user, group, account, or QOS. This allows you to 'steer' the workload toward a particular usage mix across user, group, account, and QOS dimensions. The fairshare priority factor calculation is</p>
<p><tt>Priority += FSWEIGHT * MIN(FSCAP, (</tt><br>
<tt>FSUSERWEIGHT * DeltaUserFSUsage +</tt><br>
<tt>FSGROUPWEIGHT * DeltaGroupFSUsage +</tt><br>
<tt>FSACCOUNTWEIGHT * DeltaAccountFSUsage +</tt><br>
<tt>FSQOSWEIGHT * DeltaQOSFSUsage +</tt><br>
<tt>FSCLASSWEIGHT * DeltaClassFSUsage))</tt></p>
<p>All '<b>*WEIGHT</b>' parameters above are specified on a per partition basis in the maui.cfg file. The 'Delta*Usage' components represents the difference in actual fairshare usage from a fairshare usage target. Actual fairshare usage is determined based on historical usage over the timeframe specified in the fairshare configuration. The target usage can be either a target, floor, or ceiling value as specified in the fairshare config file. The fairshare documentation covers this in detail but an example should help obfuscate things completely. Consider the following information associated with calculating the fairshare factor for job X.</p>
<p>Job X<br>
User A<br>
Group B<br>
Account C<br>
QOS D<br>
Class E</p>
<p>User A<br>
Fairshare Target: 50.0<br>
Current Fairshare Usage: 45.0</p>
<p>Group B<br>
Fairshare Target: [NONE]<br>
Current Fairshare Usage: 65.0</p>
<p>Account C<br>
Fairshare Target: 25.0<br>
Current Fairshare Usage: 35.0</p>
<p>QOS 3<br>
Fairshare Target: 10.0+<br>
Current Fairshare Usage: 25.0</p>
<p>Class E<br>
Fairshare Target: [NONE]<br>
Current Fairshare Usage: 20.0</p>
<p>PriorityWeights:<br>
FSWEIGHT 100<br>
FSUSERWEIGHT 10<br>
FSGROUPWEIGHT 20<br>
FSACCOUNTWEIGHT 30<br>
FSQOSWEIGHT 40<br>
FSCLASSWEIGHT 0</p>
<p>In this example, the Fairshare component calculation would be as follows:</p>
<p>Priority += 100 * (<br>
10 * 5 +<br>
20 * 0 +<br>
30 * (-10) +<br>
40 * 0 +<br>
0 * 0)</p>
<p>User A is 5% below his target so fairshare increases the total fairshare factor accordingly. Group B has no target so group fairshare usage is ignored. Account C is above its 10% above its fairshare usage target so this component decreases the job's total fairshare factor. QOS 3 is 15% over its target but the '+' in the target specification indicates that this is a 'floor' target, only influencing priority when fairshare usage drops below the target value. Thus, the QOS 3 fairshare usage delta does not influence the fairshare factor.</p>
<p>Fairshare is a great mechanism for influencing job turnaround time via priority to favor a particular distribution of jobs. However, it is important to realize that fairshare can only favor a particular distribution of jobs, it cannot force it. If user X has a fairshare target of 50% of the machine but does not submit enough jobs, no amount of priority favoring will get user X's usage up to 50%. See the <a href="6.3fairshare.html">Fairshare Overview</a> for more information.</p>
<h2><a name="resourcecomponent"></a>5.1.2.3 Resource (RES) Component</h2>
<p>Weighting jobs by the amount of resources requested allows a site to favor particular types of jobs. Such prioritization may allow a site to better meet site mission objectives, improve fairness, or even improve overall system utilization.</p>
<p>Resource based prioritization is valuable when you want to favor jobs based on the resources requested. This is good in three main scenarios; first, when you need to favor large resource jobs because its part of your site's mission statement; second, when you want to level the response time distribution across large and small jobs (small jobs are more easily backfilled and thus generally have better turnaround time); and finally, when you want to improve system utilization. What? Yes, system utilization actually increases as large resource jobs are pushed to the front of the queue. This keeps the smaller jobs in the back where they can be selected for backfill and thus increase overall system utilization. Its a lot like the story about filling a cup with golf balls and sand. If you put the sand in first, it gets in the way when you try to put in the golf balls. However, if you put in the golf balls first, the sand can easily be poured in around them completely filling the cup.</p>
<p>The calculation for determining the total resource priority factor is:</p>
<p><tt>Priority += <a href="a.fparameters.html#resourceweight">RESWEIGHT</a> * MIN(<a href="a.fparameters.html#resourcecap">RESCAP</a>, (</tt><br>
<tt><a href="a.fparameters.html#nodeweight">NODEWEIGHT</a> * TotalNodesRequested +</tt><br>
<tt><a href="a.fparameters.html#procweight">PROCWEIGHT</a> * TotalProcessorsRequested +</tt><br>
<tt><a href="a.fparameters.html#memweight">MEMWEIGHT</a> * TotalMemoryRequested +</tt><br>
<tt><a href="a.fparameters.html#swapweight">SWAPWEIGHT</a> * TotalSwapRequested +</tt><br>
<tt><a href="a.fparameters.html#diskweight">DISKWEIGHT</a> * TotalDiskRequested +</tt><br>
<tt><a href="a.fparameters.html#peweight">PEWEIGHT</a> * TotalPERequested))</tt></p>
<p>The sum of all weighted resources components is then multiplied by the <b>RESWEIGHT</b> parameter and capped by the <b>RESCAP</b> parameter. Memory, Swap, and Disk are all measured in megabytes (MB). The final resource component, PE, represents '<a href="3.2environment.html#PEoverview">Processor Equivalents</a>'. This component can be viewed as a processor-weighted maximum 'percentage of total resources' factor. For example, if a job requested 25% of the processors and 50% of the total memory on a 128 processor O2K system, it would have a PE value of MAX(25,50) * 128, or 64. The concept of PE's may be a little awkward to grasp initially but it is a highly effective metric in shared resource systems.</p>
<h2>5.1.2.4 Service (SERV) Component</h2>
<p>The Service component essentially specifies which service metrics are of greatest value to the site. Favoring one service subcomponent over another will generally cause that service metric to improve.</p>
<h3><a name="queuetimesubcomponent"></a>5.1.2.4.1 QueueTime (QUEUETIME) Subcomponent</h3>
<p>In the priority calculation, a job's queue time is a duration measured in minutes. Use of this subcomponent tends to prioritize jobs in a FIFO order. Favoring queue time improves queue time based fairness metrics and is probably the most widely used single job priority metric. In fact, under the initial default configuration, this is the only priority subcomponent enabled within Maui. It is important to note that within Maui, a job's queue time is not necessarily the amount of time since the job was submitted. The parameter <a href="a.fparameters.html#jobprioaccrualpolicy">JOBPRIOACCRUALPOLICY</a> allows a site to select how a job will accrue queue time based on meeting various <a href="6.2throttlingpolicies.html">throttling policies</a>. Regardless of the policy used to determine a job's queue time, this 'effective' queue time is used in the calculation of the <a href="5.1.2priorityfactors.html#queuetimesubcomponent">QUEUETIME</a>, <a href="5.1.2priorityfactors.html#xfactorsub">XFACTOR</a>, <a href="5.1.2priorityfactors.html#target">TARGETQUEUETIME</a>, and <a href="5.1.2priorityfactors.html#target">TARGETXFACTOR</a> priority subcomponent values.</p>
<p>The need for a distinct <i>effective</i> queue time is necessitated by the fact that most sites have pretty smart users and pretty smart users like to work the system, whatever system it happens to be. A common practice at some long existent sites is for some users to submit a large number of jobs and then place them on hold. These jobs remain with a hold in place for an extended period of time and when the user is ready to run a job, the needed executable and data files are linked into place and the hold released on one of these 'pre submitted' jobs. The extended hold time guarantees that this job is now the highest priority job and will be the next to run. The use of the <b>JOBPRIOACCRUALPOLICY</b> parameter can prevent this practice as well as preventing 'queue stuffers' from doing similar things on a shorter time scale. These 'queue stuffer' users submit hundreds of jobs at once so as to swamp the machine and hog use of the available compute resources. This parameter prevents the user from gaining any advantage from stuffing the queue by not allowing these jobs to accumulate any queue time based priority until they meet certain idle and/or active Maui fairness policies. (i.e., max job per user, max idle job per user, etc.)</p>
<p>As a final note, the parameter <a href="a.fparameters.html#queuetimeweight">QUEUETIMEWEIGHT</a> can be adjusted on a per QOS basis using the <a href="a.fparameters.html#qoscfg">QOSCFG</a> parameter and the <b>QTWEIGHT</b> attribute. For example, the line '<tt>QOSCFG[special] QTWEIGHT=5000</tt>' will cause jobs utilizing the QOS <tt>special</tt> to have their queue time subcomponent weight <i>increased</i> by 5000.</p>
<h3><a name="xfactorsub"></a>5.1.2.4.2 Expansion Factor (XFACTOR) Subcomponent</h3>
<p>The expansion factor subcomponent has an effect similar to the queue time factor but favors shorter jobs based on their<br>
requested wallclock run time. In its canonical form, the expansion factor (XFactor) metric is calculated as</p>
<p><tt>XFACTOR = 1 + <QUEUETIME> / <EXECUTIONTIME></tt></p>
<p>However, a couple of aspects of this calculation make its use more difficult. First, the length of time the job will actually run, 'Execution Time', is not actually known until the job completes. All that is known is how much time the job requests. Secondly, as described in the <a href="5.1.2priorityfactors.html#queuetimesubcomponent">Queue Time Subcomponent</a> section, Maui does not necessarily use the <i>raw</i> time since job submission to determine 'QueueTime' so as to prevent various scheduler abuses. Consequently, Maui uses the following modified equation:</p>
<p><tt>XFACTOR = 1 + <EFFQUEUETIME> / <WALLCLOCKLIMIT></tt></p>
<p>In the equation above, <tt>EFFQUEUETIME</tt> is the <i>effective</i> queue time subject to the <a href="a.fparameters.html#jobprioaccrualpolicy">JOBPRIOACCRUALPOLICY</a> parameter and <tt>WALLCLOCKLIMIT</tt> is the user or system specified job wallclock limit.</p>
<p>Using this equation, it can be seen that short running jobs will have an xfactor that will grow much faster over time<br>
than the xfactor associated with long running jobs. The table below demonstrates this <i>favoring</i> of short running jobs.<br></p>
<table border cols="6" width="100%" nosave="">
<tr>
<td><b>Job Queue Time</b></td>
<td>1 hour</td>
<td>2 hours</td>
<td>4 hours</td>
<td>8 hours</td>
<td>16 hours</td>
</tr>
<tr>
<td>XFactor for 1 hour job</td>
<td>1 + (1 / 1) = 2.00</td>
<td>1 + (2 / 1) = 3.00</td>
<td>1 + (4 / 1) = 5.00</td>
<td>1 + (8 / 1) = 9.00</td>
<td>1 + (16 / 1) = 17.0</td>
</tr>
<tr>
<td>XFactor for 4 hour job</td>
<td>1 + (1 / 4) = 1.25</td>
<td>1 + (2 / 4) = 1.50</td>
<td>1 + (4 / 4) = 2.00</td>
<td>1 + (8 / 4) = 3.00</td>
<td>1 + (16 / 4) = 5.0</td>
</tr>
</table>
<p>Since XFactor is calculated as a ratio of two values, it is possible for this subcomponent to be almost arbitrarily large potentially swamping the value of other priority subcomponents. This can be addressed either by using the subcomponent cap <a href="a.fparameters.html#xfactorcap">XFACTORCAP</a>, or by using the <a href="a.fparameters.html#xfminwclimit">XFMINWCLIMIT</a> parameter. If the later is used, the calculation for the xfactor subcomponent value becomes:</p>
<p><tt>XFACTOR = 1 + <EFFQUEUETIME> / MAX(<XFMINWCLIMIT>,<WALLCLOCKLIMIT>)</tt></p>
<p>The use of the <b>XFMINWCLIMIT</b> parameter allows a site to prevent very short jobs from causing the Xfactor subcomponent to grow inordinately.</p>
<p>Some sites consider XFactor to be a more <i>fair</i> scheduling performance metric than queue time. At these sites, job XFactor is given far more weight than job queue time when calculating job priority and consequently, job XFactor distribution tends to be fairly level across a wide range of job durations. (i.e., A flat XFactor distribution of 1.0 would result in a one minute job being queued on average one minute, while a 24 hour job would be queued an average of 24 hours).</p>
<p>Like queue time, the effective XFactor subcomponent weight is the sum of two weights, the <b>XFACTORWEIGHT</b> parameter and the QOS specific XFWEIGHT setting. For example, the line '<tt>QOSCFG[special] XFWEIGHT=5000</tt>' will cause jobs utilizing the QOS <tt>special</tt> to have their expansion factor subcomponent weight <i>increased</i> by 5000.</p>
<h2><a name="bypasssub"></a>5.1.2.4.3 Bypass (BYPASS) Subcomponent</h2>
<p>The bypass factor is the forgotten stepchild of the priority subcomponent family. It was originally introduced to prevent backfill based starvation. It is based on the 'bypass' count of a job where the bypass count is increased by one every time the job is 'bypassed' by a lower priority job via backfill. The calculation for this factor is simply. Over the years, the anticipated backfill starvation has never been reported. The good news is that if it ever shows up, Maui is ready!</p>
<h2><a name="target"></a>5.1.2.5 Target Service (TARG) Component</h2>
<p>The target factor component of priority takes into account job scheduling performance targets. Currently, this is limited to target expansion factor and target queue time. Unlike the expansion factor and queue time factors described earlier which increase gradually over time, the target factor component is designed to grow exponentially as the target metric is approached. This behavior causes the scheduler to do essentially 'all in its power' to make certain the scheduling targets are met.</p>
<p>The priority calculation for the target factor is:</p>
<p><tt>Priority += <a href="a.fparameters.html#targweight">TARGWEIGHT</a> * (</tt><br>
<tt>QueueTimeComponent +</tt><br>
<tt>XFactorComponent)</tt></p>
<p>The queue time and expansion factor target are specified on a per QOS basis using the 'QOSXFTARGET' and 'QOSQTTARGET' parameters. The QueueTime and XFactor component calculations are designed produce small values until the target value begins to approach at which point these components grow very rapidly. If the target is missed, these component will remain high and continue to grow but will not grow exponentially.</p>
<h2>5.1.2.6 Usage (USAGE) Component</h2>
<p><!-- FIXME needs more accurate information-->
The Usage component applies to active jobs only.</p>
<p>The priority calculation for the usage priority factor is:</p>
<p><tt>Priority += <a href="a.fparameters.html#usageweight">USAGEWEIGHT</a> * (</tt><br>
<tt><a href="a.fparameters.html#usageconsumedweight">USAGECONSUMEDWEIGHT</a>* ProcSecondsConsumed +</tt><br>
<tt><a href="a.fparameters.html#usageremainingweight">USAGEREMAININGWEIGHT</a>* ProcSecRemaining +</tt><br>
<tt><a href="a.fparameters.html#usageexecutiontimeweight">USAGEEXECUTIONTIMEWEIGHT</a>* SecondsSinceStart +</tt><br>
<tt><a href="a.fparameters.html#usagepercentweight">USAGEPERCENTWEIGHT</a>* WalltimePercent )</tt></p>
<div class="navIcons bottomIcons">
<a href="index.html"><img src="home.png" title="Home" alt="Home" border="0"></a> <a href="5.1jobprioritization.html"><img src="upArrow.png" title="Up" alt="Up" border="0"></a> <a href="5.1.1priorityoverview.html"><img src="prevArrow.png" title="Previous" alt="Previous" border="0"></a> <a href="5.1.3priorityusage.html"><img src="nextArrow.png" title="Next" alt="Next" border="0"></a>
</div>
</div>
</div>
</div>
<div class="sub-content-btm"></div>
</div>
</body>
</html>