IZ3054: job reprioritization doesn't work as expected when there are jobs with and without tickets

[joga]

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=3054]

        Issue #:      3054             Platform:     All      Reporter: joga (joga)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.0u10      CC:    None defined
        Status:       NEW              Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    pollinger (pollinger)
      QA Contact:     pollinger
          URL:
       * Summary:     job reprioritization doesn't work as expected when there are jobs with and without tickets
   Status whiteboard:
      Attachments:

     Issue 3054 blocks:
   Votes for issue 3054:


   Opened: Tue Jun 16 05:54:00 -0700 2009 
------------------------


When I have job reprioritization activated, and run my cluster in overload (more cpu bound jobs than cpus), the reprioritization is broken
in the following scenario:

I have 2 Projects, A and B, having functional shares of 10 and 20.

In the scheduler config, I have
reprioritize_interval             00:00:40
weight_tickets_functional         1000000

One queue instance available, with 4 slots.

I submit the following jobs:
qsub -P A $SGE_ROOT/examples/jobs/worker.sh
qsub -P B $SGE_ROOT/examples/jobs/worker.sh
qsub $SGE_ROOT/examples/jobs/worker.sh
qsub $SGE_ROOT/examples/jobs/worker.sh

I would expect the job of project B getting significantly more cpu (double) than the job of project A, and the jobs without project getting
very low cpu.

I see the jobs without project getting very low cpu,
but the jobs for projects A and B get the same cpu, and they have the same nice value.

When I only submit jobs having a project it works as expected:
qsub -P A $SGE_ROOT/examples/jobs/worker.sh
qsub -P B $SGE_ROOT/examples/jobs/worker.sh

I see the job for project B getting arround twice the cpu as the job for project A,
which is what I would expect. The jobs nice values are adjusted regularly to ensure they get the granted shares.