Run Scheduling Process - perfsonar/pscheduler GitHub Wiki

Task Selection

The scheduler gathers a list of tasks which have not run enough times to meet their maximum and do not have runs scheduled up to the scheduling horizon (nominally 24 hours) and are not already currently being scheduled.

The list is sorted ascending by the time when the next run should occur. This puts nearer-term runs at the front of the line for scheduling and puts off those that can be done later.

The sorted list is limited by the number of workers in the scheduler's pool less any that are already occupied. (The default pool size is 50, but this is configurable.)

Each item in the final list results in the spawning of a worker that does the per-task scheduling shown below.

Per-Task Scheduling

The database in each pScheduler node contains a table with all runs which have been scheduled and ran, are running or will run later. (This is called, unsurprisingly, the run table.)

The lead participant calculates the acceptable range of times for a run to occur. This range begins at what would be the ideal start time and ends at the ideal end time (ideal start time plus run duration) plus any allowable slip. For example, a 10-second run with an ideal start time of 12:00:00 and five minutes of slip would have an acceptable range of [12:00:00, 12:05:10).

The lead participant asks all participants (including itself) to propose time ranges for a run of the task that are at least as long as the run duration, fall within the acceptable range and can run in parallel with other runs (see Scheduling Classes).

The lead participant calculates a set of the intersections between its own proposals and those of the other participants. This set represents the possible times the run can happen on all participants. If the set is empty, scheduling fails.

The lead participant selects a time from that set based on the scheduling parameters and posts runs to itself and all of the other participants. If posting to all participants fails, scheduling fails and any successfully-posted runs are deleted.

Priorities

To handle priorities, the scheduling worker makes two attempts to schedule the run:

The first attempt is with the neutral priority value of zero. This allows the run to be scheduled to avoid higher-priority runs that have already been scheduled. If this attempt succeeds, scheduling is complete.

The second attempt is with the task's actual priority, which will force preemption of lower-priority runs.

More information on priorities can be found in this video.