CPU Scheduling Visualizer

An interactive web visualizer for 9 CPU scheduling algorithms: build a process set with CPU and I/O bursts, run any algorithm, and compare them on a Gantt chart by average completion, turnaround, waiting, and response time.

ROLE: Developer
PERIOD: 2021
DOMAIN: Operating Systems
STATUS: Published
CODE: GitHub ↗
DEMO: Live ↗

OVERVIEW

An interactive web visualizer for 9 CPU scheduling algorithms (FCFS, SJF, SRTF, LJF, LRTF, Priority NP/P, Round Robin, HRRN). You build a process set with CPU and I/O bursts, arrival times, and priorities, set the context-switch time and time quantum, then run any algorithm and watch the schedule build on a Gantt chart. All algorithms are compared on the same input by average completion, turnaround, waiting, and response time, with a Round Robin sweep across time quanta. It is a single ~1,105-line vanilla-JS app whose core scheduling logic is also extracted into a Node test suite covering all 9 algorithms, and it is the implementation behind a published IEEE paper (AIMV 2021).

ARRIVED AS

CPU scheduling algorithms are easy to state and hard to feel: the difference between FCFS, Round Robin, and HRRN only becomes intuitive when you watch the same processes scheduled different ways and compare the numbers. The goal was a browser tool to do exactly that, build a process set, run any of the standard algorithms, and see the schedule and its metrics side by side.

This started as an operating-systems project and became the implementation behind a published IEEE paper (AIMV 2021) on applying scheduling algorithms to vaccine distribution. The visualizer's job is pedagogical and comparative: let someone enter a set of processes with CPU and I/O bursts, pick a scheduling policy, watch the schedule build on a Gantt chart, and then compare every algorithm on the same input by the four metrics that matter, completion, turnaround, waiting, and response time.

WHAT I BUILT

01Implements 9 algorithms, FCFS, SJF, SRTF, LJF, LRTF, Priority (non-preemptive and preemptive), Round Robin, and HRRN, as one discrete-event scheduler driven by a per-tick ready queue.
02Models each process with both CPU and I/O bursts, arrival time, and priority, with configurable context-switch time, time quantum, and a high/low priority preference.
03Renders the resulting schedule as a Gantt and timeline chart and compares all algorithms by average completion, turnaround, waiting, and response time, including a Round Robin sweep across time quanta.
04Extracts the core scheduling logic into a Node-runnable test suite covering all 9 algorithms, so the engine can be verified outside the browser.

WHAT CHANGED

Runs entirely in the browser on GitHub Pages: define a custom process set and try every algorithm on it with no setup.
Turns scheduling theory into a side-by-side comparison, making the trade-offs between algorithms visible on the same input.
Built as the implementation behind a published IEEE paper (AIMV 2021) that applied CPU-scheduling ideas to vaccine-distribution scheduling.

Data flow

click a stage

Enter arrival times, alternating CPU and I/O bursts, and (optionally) priorities, plus global settings like time quantum and context-switch time.

COMPONENT

Input / process table

Captures the process set, arrival times, CPU and I/O burst pairs, priorities, and the global scheduling settings.

Decisions, with the cost of each.

A decision without its trade-off is marketing. Each row says what was chosen, why, and what it gave up.

DECISIONBECAUSEAT THE COST OF

One discrete-event scheduler, not nine separate implementations

All nine policies differ only in how the next process is chosen at each tick. A single time-stepped engine with a pluggable selection rule keeps the ready-queue, I/O-blocking, and context-switch logic in one place instead of duplicated nine times.

A standalone function per algorithm (lots of duplicated queue and I/O handling, easy to drift out of sync).

Model I/O bursts, not just CPU bursts

Real processes alternate CPU and I/O. Adding an I/O block queue alongside the ready queue makes the schedules realistic and lets preemptive policies behave as they actually would when a process blocks.

CPU bursts only (simpler, but an unrealistic model that hides how scheduling interacts with I/O).

Extract the core logic into a Node test suite

Scheduling logic embedded in DOM event handlers is hard to trust. Pulling the engine and the nine algorithms into a plain module that runs under Node makes the results testable headlessly, separate from the UI.

Manual checking in the browser (slow, not repeatable, no regression safety).

The part that mattered.

The numbers behind the work, and the code that produced them.

schedulers: 9 algorithms; FCFS · SJF · SRTF · LJF · LRTF · Priority · RR · HRRN
compared: 4 metrics; completion · turnaround · waiting · response
vanilla JS: 1,105 lines; one engine + a Node test suite
paper implementation: IEEE 2021; AIMV, applied to vaccine scheduling

The metrics every scheduler is judged byjavascript

function setOutput(input, output) {
  const n = input.processId.length;
  for (let i = 0; i < n; i++) {
    output.turnAroundTime[i] = output.completionTime[i] - input.arrivalTime[i];
    output.waitingTime[i]    = output.turnAroundTime[i] - input.totalBurstTime[i];
  }
  output.schedule = reduceSchedule(output.schedule);
  output.averageTimes = outputAverageTimes(output, n);
}

function outputAverageTimes(output, n) {
  let ct = 0, tat = 0, wt = 0, rt = 0;
  output.completionTime.forEach(e => ct += e);
  output.turnAroundTime.forEach(e => tat += e);
  output.waitingTime.forEach(e => wt += e);
  output.responseTime.forEach(e => rt += e);
  return [ct / n, tat / n, wt / n, rt / n];
}

Turnaround is completion minus arrival, waiting is turnaround minus total burst, the textbook definitions. Averaging the four metrics across processes is what makes the cross-algorithm comparison meaningful: every policy is scored on the same numbers from the same input.

A ready queue and an I/O block queue, per tickjavascript

function updateReadyQueue(currentTimeLog) {
  // processes that have arrived become ready
  let candidatesRemain = currentTimeLog.remain
    .filter(e => input.arrivalTime[e] <= currentTimeLog.time);
  // processes whose I/O has finished come back
  let candidatesBlock = currentTimeLog.block
    .filter(e => utility.returnTime[e] <= currentTimeLog.time);

  if (candidatesRemain.length > 0) currentTimeLog.move.push(0);
  if (candidatesBlock.length > 0) currentTimeLog.move.push(5);
}

At each time step the scheduler refreshes two queues: newly arrived processes joining the ready queue, and processes returning from an I/O block. Modeling the block queue alongside the ready queue is what makes the schedules reflect real CPU/I/O interleaving rather than a CPU-only abstraction.

✓ LEARNED

Nine algorithms collapse into one engine once you see that they differ only in the next-process selection rule, the queueing and I/O logic is shared.
Adding an I/O block queue is what separates a toy CPU-only model from schedules that behave the way an OS course actually describes.
Lifting logic out of DOM handlers into a Node-testable module turned a browser demo into something with a real regression suite behind it.