Tardis scheduling policy

From CUC3
Jump to navigation Jump to search

Now is a good time to review tardis's scheduling policy as we have had the machine in service for a few months.

Current policy

Fairshare and priority

Every individual user has a fairshare target of 20% of the machine. If you go over that then you get penalties; under it and you get bonuses. There are also two QOS (quality of service) groups, which also have fairshare targets. These are based on how the machine was funded: the 'stuart' group (Stuart Althorpe's research group) get 52% and the 'portfolio' group (everyone else) get 48%.

Fairshare targets and usage can be seen by running 'diagnose -f'

The fairshare calculation takes the last six weeks of usage into account, decaying it at a rate of 0.8 per week.

Priority is currently: 20 * ( personal fairshare bonus/penalty + group fairshare bonus/penalty ) + job expansion factor .

Job expansion factor rises with time spent on the queue, but rises faster for short jobs. The reason for using that and not basic queue time is that it helps the very short (30 min) test jobs to run. It makes practically no difference when compared to the fairshare numbers, but ensures that every job eventually runs.

Priority calculations for all queued jobs can be seen by running 'diagnose -p'

Throttling policies

There is one throttling policy in use: any user may only have four jobs in the 'Idle' state at any given time. This avoids queue stuffing. However it does not help when one person has a very big fairshare bonus and submits a lot of jobs, because every job that gets to run is replaced in the queue immediately.


Reservation and Backfill

The current problem

Things we could change and their likely effects

  • Shorter or fewer fairshare windows, so machine has shorter memory
  • Dilute group fairshare (ie give personal fairshare a bigger multiplier than 20)
  • Max processors per person limit
  • Max processor-seconds per person limit