SCHED_CONF(5)              Grid Engine File Formats              SCHED_CONF(5)



[1mNAME[0m
       sched_conf - Grid Engine default scheduler configuration file

[1mDESCRIPTION[0m
       [4msched_conf[24m  defines  the  configuration  file  format for Grid Engine's
       default scheduler provided by [4msge_schedd[24m(8).  In order  to  modify  the
       configuration,  use  the  graphical  user's  interface  [4mqmon[24m(1)  or the
       [4m-msconf[24m option of the [4mqconf[24m(1) command. A default configuration is pro-
       vided together with the Grid Engine distribution package.

[1mFORMAT[0m
       The following parameters are recognized by the Grid Engine scheduler if
       present in [4msched_conf[24m:

   [1malgorithm[0m
       Allows for the selection of alternative scheduling algorithms.

       Currently [1mdefault [22mis the only allowed setting.

   [1mload_formula[0m
       A simple algebraic expression used to derive  a  single  weighted  load
       value  from all or part of the load parameters reported by [4msge_execd[24m(8)
       for each host and from all or part of  the  consumable  resources  (see
       [4mcomplex[24m(5))  being  maintained for each host.  The load formula expres-
       sion syntax is that of a summation weighted load values, that is:

              load_val1[*w1][{+|-}load_val2[*w2][{+|-}...]]

       [1mNote[22m, no blanks are allowed in the load formula.
       The load values and consumable resources (load_val1, ...)   are  speci-
       fied by the name defined in the complex (see [4mcomplex[24m(5)).
       [1mNote:  [22mAdministrator defined load values (see the [1mload_sensor [22mparameter
       in [4msge_conf[24m(5) for details) and consumable resources available for  all
       hosts  (see [4mcomplex[24m(5)) may be used as well as Grid Engine default load
       parameters.
       The weighting factors  (w1,  ...)  are  positive  integers.  After  the
       expression  is  evaluated for each host the results are assigned to the
       hosts and are used to sort the  hosts  corresponding  to  the  weighted
       load. The sorted host list is used to sort queues subsequently.
       The default load formula is "np_load_avg".

   [1mjob_load_adjustments[0m
       The  load, which is imposed by the Grid Engine jobs running on a system
       varies in time, and often, e.g. for the CPU load, requires some  amount
       of  time  to  be  reported in the appropriate quantity by the operating
       system. Consequently, if a job was started very recently, the  reported
       load  may  not provide a sufficient representation of the load which is
       already imposed on that host by the job. The reported load  will  adapt
       to  the  real  load  over  time,  but  the period of time, in which the
       reported load is too low, may already lead to  an  oversubscription  of
       that   host.   Grid   Engine   allows   the  administrator  to  specify
       [1mjob_load_adjustments [22mwhich are used in the  Grid  Engine  scheduler  to
       compensate for this problem.
       The  [1mjob_load_adjustments  [22mare  specified  as a comma separated list of
       arbitrary load parameters or consumable resources and (separated by  an
       equal sign) an associated load correction value. Whenever a job is dis-
       patched to a host by [4msge_schedd[24m(8), the load parameter  and  consumable
       value  set  of  that  host  is  increased by the values provided in the
       [1mjob_load_adjustments [22mlist. These correction values are decayed linearly
       over  time  until  after  [1mload_adjustment_decay_time [22mfrom the start the
       corrections reach the value 0.  If  the  [1mjob_load_adjustments  [22mlist  is
       assigned  the  special  denominator  NONE, no load corrections are per-
       formed.
       The adjusted load and consumable values are used to  compute  the  com-
       bined  and weighted load of the hosts with the [1mload_formula [22m(see above)
       and to compare the load and consumable values against the load  thresh-
       old  lists defined in the queue configurations (see [4mqueue_conf[24m(5)).  If
       the [1mload_formula [22mconsists simply of the default CPU load average param-
       eter [4mnp_load_avg[24m, and if the jobs are very compute intensive, one might
       want to set the [1mjob_load_adjustments [22mlist  to  [4mnp_load_avg=1.00[24m,  which
       means  that  every  new job dispatched to a host will require 100 % CPU
       time, and thus the machine's load is instantly increased by 1.00.

   [1mload_adjustment_decay_time[0m
       The load corrections  in  the  "[1mjob_load_adjustments[22m"  list  above  are
       decayed  linearly  over time from the point of the job start, where the
       corresponding load or consumable parameter is raised by the  full  cor-
       rection   value,   until   after   a   time   period  of  "[1mload_adjust-[0m
       [1mment_decay_time[22m", where the correction becomes  0.  Proper  values  for
       "[1mload_adjustment_decay_time[22m" greatly depend upon the load or consumable
       parameters used and the specific operating system(s).  Therefore,  they
       can  only  be  determined  on-site and experimentally.  For the default
       [4mnp_load_avg[24m load parameter a "[1mload_adjustment_decay_time[22m" of 7  minutes
       has proven to yield reasonable results.

   [1mmaxujobs[0m
       The  maximum  number of jobs any user may have running in a Grid Engine
       cluster at the same time. If set to 0 (default) the users  may  run  an
       arbitrary number of jobs.

   [1mschedule_interval[0m
       At  the time [4msge_schedd[24m(8) initially registers to [4msge_qmaster[24m(8) [1msched-[0m
       [1mule_interval [22mis used to set the time interval in  which  [4msge_qmaster[24m(8)
       sends scheduling event updates to [4msge_schedd[24m(8).  A scheduling event is
       a status change that has occurred within [4msge_qmaster[24m(8) which may trig-
       ger or affect scheduler decisions (e.g. a job has finished and thus the
       allocated resources are available again).
       In the Grid Engine default scheduler the arrival of a scheduling  event
       report  triggers a scheduler run. The scheduler waits for event reports
       otherwise.
       [1mSchedule_interval [22mis a time value (see [4mqueue_conf[24m(5) for  a  definition
       of the syntax of time values).

   [1mqueue_sort_method[0m
       This  parameter  determines  in  which order several criteria are taken
       into account to product a sorted queue list.  Currently,  two  settings
       are  valid: [1mseqno [22mand [1mload[22m. However in both cases, Grid Engine attempts
       to maximize the number of soft requests (see [4mqsub[24m(1) [1m-s  [22moption)  being
       fulfilled by the queues for a particular as the primary criterion.
       Then,  if  the [1mqueue_sort_method [22mparameter is set to [1mseqno[22m, Grid Engine
       will use the [1mseq_no [22mparameter as configured in the current  queue  con-
       figurations (see [4mqueue_conf[24m(5)) as the next criterion to sort the queue
       list. The [1mload_formula [22m(see above) has only a  meaning  if  two  queues
       have  equal  sequence numbers.  If [1mqueue_sort_method [22mis set to [1mload [22mthe
       load according the [1mload_formula [22mis the  criterion  after  maximizing  a
       job's  soft  requests and the sequence number is only used if two hosts
       have the same load.  The sequence number sorting is most useful if  you
       want  to  define  a  fixed order in which queues are to be filled (e.g.
       the cheapest resource first).

       The default for this parameter is [1mload[22m.

   [1mhalftime[0m
       When executing under a share based policy, the scheduler  "ages"  (i.e.
       decreases)  usage to implement a sliding window for achieving the share
       entitlements as defined by the share tree.  The  [1mhalftime  [22mdefines  the
       time interval in which accumulated usage will have been decayed to half
       its original value. Valid values are specified in hours or according to
       the time format as specified in [4mqueue_conf[24m(5).

   [1musage_weight_list[0m
       Grid  Engine  accounts  for  the consumption of the resources CPU-time,
       memory and IO to determine the usage which is imposed on a system by  a
       job. A single usage value is computed from these three input parameters
       by multiplying the individual values by weights and adding them up. The
       weights are defined in the [1musage_weight_list[22m. The format of the list is

              cpu=wcpu,mem=wmem,io=wio

       where wcpu, wmem and wio are the configurable weights. The weights  are
       real number. The sum of all tree weights should be 1.

   [1mcompensation_factor[0m
       Determines  how fast Grid Engine should compensate for past usage below
       of above the share entitlement defined in the share  tree.  Recommended
       values are between 2 and 10, where 10 means faster compensation.

   [1mweight_user[0m
       The  relative  importance  of the user shares in the functional policy.
       Values are of type real.

   [1mweight_project[0m
       The relative importance of the project shares in the functional policy.
       Values are of type real.

   [1mweight_department[0m
       The relative importance of the department shares in the functional pol-
       icy. Values are of type real.

   [1mweight_job[0m
       The relative importance of the job shares  in  the  functional  policy.
       Values are of type real.

   [1mweight_tickets_functional[0m
       The  maximum number of functional tickets available for distribution by
       Grid Engine. Determines the relative importance of the functional  pol-
       icy.  See under [4msge_priority[24m(5) for an overview on job priorities.

   [1mweight_tickets_share[0m
       The maximum number of share based tickets available for distribution by
       Grid Engine. Determines the relative importance of the share tree  pol-
       icy. See under [4msge_priority[24m(5) for an overview on job priorities.

   [1mweight_deadline[0m
       The  weight  applied  on  the  remaining time until a jobs latest start
       time. Determines the relative importance of  the  deadline.  See  under
       [4msge_priority[24m(5) for an overview on job priorities.

   [1mweight_waiting_time[0m
       The  weight  applied  on the jobs waiting time since submission. Deter-
       mines the relative importance of the waiting time.  See under  [4msge_pri-[0m
       [4mority[24m(5) for an overview on job priorities.

   [1mweight_urgency[0m
       The weight applied on jobs normalized urgency when determining priority
       finally used.  Determines the  relative  importance  of  urgency.   See
       under [4msge_priority[24m(5) for an overview on job priorities.

   [1mweight_ticket[0m
       The  weight applied on normalized ticket amount when determining prior-
       ity finally used.  Determines the relative  importance  of  the  ticket
       policies.  See under [4msge_priority[24m(5) for an overview on job priorities.

   [1mflush_finish_sec[0m
       The parameters are provided for tuning the system's  scheduling  behav-
       ior.   By default, a scheduler run is triggered in the scheduler inter-
       val. When this parameter is set to 1 or larger, the scheduler  will  be
       triggered x seconds after a job has finished. Setting this parameter to
       0 disables the flush after a job has finished.

   [1mflush_submit_sec[0m
       The parameters are provided for tuning the system's  scheduling  behav-
       ior.   By default, a scheduler run is triggered in the scheduler inter-
       val.  When this parameter is set to 1 or larger, the scheduler will  be
       triggered   x  seconds after a job was submitted to the system. Setting
       this parameter to 0 disables the flush after a job was submitted.

   [1mschedd_job_info[0m
       The default scheduler can keep track why jobs could  not  be  scheduled
       during  the  last scheduler run. This parameter enables or disables the
       observation.  The value [1mtrue [22menables the monitoring [1mfalse [22mturns it off.

       It  is also possible to activate the observation only for certain jobs.
       This will be done if the parameter is set to  [1mjob_list  [22mfollowed  by  a
       comma separated list of job ids.

       The  user  can  obtain the collected information with the command qstat
       -j.

   [1mparams[0m
       This is foreseen for passing additional parameters to the  Grid  Engine
       scheduler. The following values are recognized:

       [4mDURATION_OFFSET[0m
              If set, overrides the default of value 60 seconds.  This parame-
              ter is used by the Grid Engine scheduler when planning  resource
              utilization as the delta between net job runtimes and total time
              until resources become available again. Net job runtime as spec-
              ified  with  -l  h_rt=...   or  -l  s_rt=... or [1mdefault_duration[0m
              always differs from total job runtime due to delays  before  and
              after  actual  job start and finish. Among the delays before job
              start is the time until the end of a [1mschedule_interval[22m, the time
              it  takes to deliver a job to [4msge_execd[24m(8) and the delays caused
              by [1mprolog [22min [4mqueue_conf[24m(5) , [1mstart_proc_args  [22min  [4msge_pe[24m(5)  and
              [1mstarter_method  [22min  [4mqueue_conf[24m(5)  ([1mnotify[22m,  [1mterminate_method [22mor
              [1mcheckpointing[22m), procedures run after acutal job finish, such  as
              [1mstop_proc_args [22min [4msge_pe[24m(5) or [1mepilog [22min [4mqueue_conf[24m(5) , and the
              delay until a new [1mschedule_interval[22m.
              If the offset is too low, resource reservations (see  [1mmax_reser-[0m
              [1mvation[22m)  can be delayed repeatedly due to an overly optistic job
              circulation time.

       [4mJC_FILTER[0m
              If set to true, the scheduler limits the number of jobs it looks
              at  during  a scheduling run. At the beginning of the scheduling
              run it assigns each job a specific category, which is  based  on
              the  job's  requests,  priority settings, and the job owner. All
              scheduling policies will assign the same importance to each  job
              in  one category. Therefore the number of jobs per category have
              a FIFO order and can be limited to the number of free  slots  in
              the system.

              A exception are jobs, which request a resource reservation. They
              are included regardless of the number of jobs in a category.

              This setting is turned off per default,  because  in  very  rare
              cases,  the  scheduler  can  make  a  wrong decision. It is also
              advised to turn report_pjob_tickets off.  Otherwise  qstat  -ext
              can report outdated ticket amounts. The information shown with a
              qstat -j for a job, that was excluded in a  scheduling  run,  is
              very limited.

       [4mPROFILE[0m
              If set equal to 1, the scheduler logs profiling information sum-
              marizing each scheduling run.

       [4mMONITOR[0m
              If set equal to 1, the scheduler records  information  for  each
              scheduling  run  allowing to reproduce job resources utilization
              in the file [4m<sge_root>/<cell>/common/schedule[24m.

       [4mSELECT_PE_RANGE_ALG[0m
              This parameter sets the algorithm for the pe range  computation.
              The  default  is  automatic, which means that the scheduler will
              select the best one, and it should not be necessary to change it
              to  a different setting in normal operation. If a custom setting
              is needed, the following values are available:
              auto       : the scheduler selects the best algorithm
              least      : starts the resource matching with the  lowest  slot
              amount first
              bin         :  starts the resource matching in the middle of the
              pe slot range
              highest    : starts the resource matching with the highest  slot
              amount first

       Changing  [1mparams [22mwill take immediate effect.  The default for [1mparams [22mis
       none.

   [1mreprioritize_interval[0m
       Interval (HH:MM:SS) to reprioritize jobs on the exec hosts based on the
       current  ticket  amount for the running jobs. If the interval is set to
       00:00:00 the reprioritization is  turned  off.  The  default  value  is
       00:00:00.

   [1mreport_pjob_tickets[0m
       This  parameter  allows to tune the system's scheduling run time. It is
       used to enable / disable the reporting of pending job  tickets  to  the
       qmaster.  It does not influence the tickets calculation. The sort order
       of jobs in qstat and qmon is only based on the submit  time,  when  the
       reporting is turned off.
       The reporting should be turned of in a system with very large amount of
       jobs by setting this param to "false".

   [1mhalflife_decay_list[0m
       The halflife_decay_list allows to configure different decay  rates  for
       the "finished_jobs usage types, which is used in the pending job ticket
       calculation to account for jobs which have just ended. This allows  the
       user  the  pending jobs algorithm to count finished jobs against a user
       or project for a configurable decayed  time  period.  This  feature  is
       turned off by default, and the halftime is used instead.
       The  halflife_decay_list  also  allows one to configure different decay
       rates for each usage type being tracked (cpu, io, and mem). The list is
       specified in the following format:

              <USAGE_TYPE>=<TIME>[:<USAGE_TYPE>=<TIME>[:<USAGE_TYPE>=<TIME>]]

       <Usage_TYPE> can be one of the following: cpu, io, or mem.
       <TIME>  can  be  -1, 0 or a timespan specified in minutes. If <TIME> is
       -1, only the usage of currently running jobs is used. 0 means that  the
       usage is not decayed.

   [1mpolicy_hierarchy[0m
       This  parameter  sets  up  a dependency chain of ticket based policies.
       Each ticket based policy in the dependency chain is influenced  by  the
       previous policies and influences the following policies. A typical sce-
       nario is to assign precedence for the override policy over  the  share-
       based  policy. The override policy determines in such a case how share-
       based tickets are assigned among jobs of  the  same  user  or  project.
       Note  that  all  policies contribute to the ticket amount assigned to a
       particular job regardless of the policy hierarchy definition.  Yet  the
       tickets  calculated  in each of the policies can be different depending
       on "[4mPOLICY_HIERARCHY[24m".

       The "[4mPOLICY_HIERARCHY[24m" parameter can be a up to 3 letter combination of
       the  first letters of the 3 ticket based policies S(hare-based), F(unc-
       tional) and O(verride). So a value "OFS" means that the override policy
       takes  precedence  over the functional policy, which finally influences
       the share-based policy.  Less than 3 letters  mean  that  some  of  the
       policies do not influence other policies and also are not influenced by
       other policies. So a value of "FS" means  that  the  functional  policy
       influences  the  share-based  policy  and that there is no interference
       with the other policies.

       The special value "NONE" switches off policy hierarchies.

   [1mshare_override_tickets[0m
       If set to "true" or  "1",  override  tickets  of  any  override  object
       instance  are shared equally among all running jobs associated with the
       object. The pending jobs will get as many  override  tickets,  as  they
       would  have, when they were running. If set to "false" or "0", each job
       gets the full value of the override tickets associated with the object.
       The default value is "true".

   [1mshare_functional_shares[0m
       If  set  to  "true"  or "1", functional shares of any functional object
       instance are shared among all the jobs associated with the  object.  If
       set  to  "false"  or "0", each job associated with a functional object,
       gets the full functional shares of that object. The  default  value  is
       "true".

   [1mmax_functional_jobs_to_schedule[0m
       The  maximum  number of pending jobs to schedule in the functional pol-
       icy.  The default value is 200.

   [1mmax_pending_tasks_per_job[0m
       The maximum number of subtasks per pending array job to schedule.  This
       parameter  exists  in  order to reduce scheduling overhead. The default
       value is 50.

   [1mmax_reservation[0m
       The maximum number of reservations scheduled within a  schedule  inter-
       val.   When  a  runnable  job  can  not be started due to a shortage of
       resources a reservation can be scheduled  instead.  A  reservation  can
       cover consumable resources with the global host, any execution host and
       any queue. For parallel jobs  reservations  are  done  also  for  slots
       resource  as specified in [4msge_pe[24m(5).  As job runtime the maximum of the
       time specified with -l h_rt=... or -l s_rt=...  is  assumed.  For  jobs
       that  have  neither  of them the default_duration is assumed.  Reserva-
       tions prevent jobs of lower priority as  specified  in  [4msge_priority[24m(5)
       from utilizing the reserved resource quota during the while of reserva-
       tion.  Jobs of lower priority are allowed  to  utilize  those  reserved
       resources  only if their prospective job end is before the start of the
       reservation (backfilling).  Reservation is done only for  non-immediate
       jobs  (-now  no) that request reservation (-R y). If max_reservation is
       set to "0" no job reservation is done.

       Note, that reservation scheduling  can  be  performance  consuming  and
       hence reservation scheduling is switched off by default. Since reserva-
       tion scheduling performance consumption is known to grow with the  num-
       ber  of  pending  jobs use of -R y option is recommended only for those
       jobs actually queuing for  bottleneck  resources.   Together  with  the
       max_reservation  parameter  this  technique  can be used to narrow down
       performance impacts.

   [1mdefault_duration[0m
       When job reservation is enabled through  max_reservation  [4msched_conf[24m(5)
       parameter the default duration is assumed as runtime for jobs that have
       neither -l h_rt=...  nor  -l  s_rt=...  specified.  In  contrast  to  a
       h_rt/s_rt time limit the default_duration is not enforced.

[1mFILES[0m
       [4m<sge_root>/<cell>/common/sched_configuration[0m
                  sge_schedd configuration

[1mSEE ALSO[0m
       [4msge_intro[24m(1),   [4mqalter[24m(1),  [4mqconf[24m(1),  [4mqstat[24m(1),  [4mqsub[24m(1),  [4mcomplex[24m(5),
       [4mqueue_conf[24m(5),  [4msge_execd[24m(8),  [4msge_qmaster[24m(8),   [4msge_schedd[24m(8).    [4mGrid[0m
       [4mEngine[24m [4mInstallation[24m [4mand[24m [4mAdministration[24m [4mGuide[0m

[1mCOPYRIGHT[0m
       See [4msge_intro[24m(1) for a full statement of rights and permissions.



GE 6.0                   $Date: 2007/01/05 20:31:01 $            SCHED_CONF(5)
