feat: Add English documentation, switch license to MIT, and include JOSS paper.
This commit is contained in:
Lucas Guerra committed
1 parent
571d8e51d2
commit
cb05314232
10 files changed
+646
-4
No files matched your search
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025 Lucas Rayan Guerra
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
+208
@@ -0,0 +1,208 @@
|
||||
# 🖥️ Process Scheduler Simulator
|
||||
|
||||
> An interactive educational tool for visualizing and comparing classical CPU scheduling algorithms from Operating Systems.
|
||||
|
||||
[](https://react.dev/)
|
||||
[](https://www.typescriptlang.org/)
|
||||
[](https://vitejs.dev/)
|
||||
[](https://tailwindcss.com/)
|
||||
[](https://vitest.dev/)
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
|
||||
---
|
||||
|
||||
## ✨ What is it?
|
||||
|
||||
The **Process Scheduler Simulator (PSS)** runs entirely in the browser — no server, no system dependencies. You define the processes, choose the algorithm, and watch the simulation unfold in real time through the Gantt chart.
|
||||
|
||||
Ideal for:
|
||||
- 📚 Operating Systems students who want to visualize what was once only theory
|
||||
- 👩🏫 Instructors looking for an interactive classroom tool
|
||||
- 🔍 Professionals revisiting OS fundamentals
|
||||
|
||||
A live demo is available at: **https://pss.lucasrguerra.dev.br/**
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- [Node.js](https://nodejs.org/) 20+
|
||||
- npm 10+
|
||||
|
||||
### Local installation and run
|
||||
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/lucasrguerra/pss.git
|
||||
cd pss
|
||||
|
||||
# Install dependencies
|
||||
npm install
|
||||
|
||||
# Start the development server
|
||||
npm run dev
|
||||
```
|
||||
|
||||
Open [http://localhost:5173](http://localhost:5173) in your browser.
|
||||
|
||||
### Production build
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
npm run preview
|
||||
```
|
||||
|
||||
### With Docker
|
||||
|
||||
```bash
|
||||
docker compose up
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎮 How to use
|
||||
|
||||
1. **Create your processes** — In the left panel, add processes by defining name, arrival time, priority, and a sequence of bursts (CPU and I/O). Or use the random generator to get started quickly.
|
||||
2. **Configure the scheduler** — Choose an algorithm and adjust the parameters (quantum for RR, aging for Priority, etc.).
|
||||
3. **Run the simulation** — Use the Play/Pause/Step controls to run the simulation at the speed you want (0.25× to 4×).
|
||||
4. **Analyze the results** — The Gantt chart shows each process's state in real time. At the end, the metrics panel displays turnaround, waiting time, throughput, and more.
|
||||
|
||||
> 💡 **Tip:** Load one of the built-in **presets** to see classic phenomena such as the FCFS convoy effect or priority starvation.
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Supported Algorithms
|
||||
|
||||
| Algorithm | Preemptive? | Parameters |
|
||||
|-----------|:-----------:|------------|
|
||||
| **FCFS** — First Come, First Served | ❌ | — |
|
||||
| **SJF** — Shortest Job First | ❌ | — |
|
||||
| **SRTF** — Shortest Remaining Time First | ✅ | — |
|
||||
| **Round Robin (RR)** | ✅ | Quantum |
|
||||
| **Priority NP** — Non-Preemptive Priority | ❌ | Aging (optional) |
|
||||
| **Priority P** — Preemptive Priority | ✅ | Aging (optional) |
|
||||
| **HRRN** — Highest Response Ratio Next | ❌ | — |
|
||||
| **Multilevel Queue** | ✅ | Quantum per queue |
|
||||
|
||||
> See the [algorithms documentation](./docs/algorithms.en.md) for details on how each one works.
|
||||
|
||||
---
|
||||
|
||||
## 📊 Computed Metrics
|
||||
|
||||
For each simulated process, PSS automatically computes:
|
||||
|
||||
- **Response Time** — time until the first CPU usage
|
||||
- **Turnaround Time** — total time from arrival to completion
|
||||
- **Waiting Time** — total time spent in the Ready queue
|
||||
- **CPU Time / I/O Time** — effective time in each type of burst
|
||||
- **CPU Utilization** — percentage of turnaround time spent on CPU
|
||||
- **Bound Type** — automatic classification as CPU Bound, I/O Bound, or Balanced
|
||||
|
||||
Globally: averages for response/turnaround/waiting, throughput, and overall CPU utilization.
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ Project Structure
|
||||
|
||||
```
|
||||
src/
|
||||
├── core/ # Pure logic — no React
|
||||
│ ├── algorithms/ # Implementation of each algorithm
|
||||
│ │ ├── base.ts # Abstract class BaseScheduler
|
||||
│ │ ├── fcfs.ts
|
||||
│ │ ├── sjf.ts
|
||||
│ │ ├── rr.ts
|
||||
│ │ ├── priority.ts
|
||||
│ │ ├── priority_rr.ts
|
||||
│ │ ├── hrrn.ts
|
||||
│ │ ├── multilevel.ts
|
||||
│ │ └── index.ts # Dispatch by algorithm
|
||||
│ ├── engine.ts # SimulationEngine — orchestrates the ticks
|
||||
│ ├── metrics.ts # Per-process and global metrics computation
|
||||
│ ├── types.ts # All TypeScript interfaces
|
||||
│ └── presets.ts # Pre-defined scenarios
|
||||
│
|
||||
├── store/ # Global state with Zustand
|
||||
├── components/ # React components
|
||||
│ ├── ProcessPanel/ # Process creation and editing
|
||||
│ ├── SchedulerPanel/ # Algorithm selection and parameters
|
||||
│ ├── ControlBar/ # Play, Pause, Step, Reset, speed
|
||||
│ ├── GanttChart/ # Interactive Gantt chart
|
||||
│ ├── MetricsPanel/ # Table, charts, and global metrics
|
||||
│ └── shared/ # Buttons, badges, tooltips, modals
|
||||
│
|
||||
└── hooks/ # Custom hooks (animation loop, export, etc.)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📦 Available Presets
|
||||
|
||||
Load classic scenarios with a single click to explore OS phenomena:
|
||||
|
||||
| Preset | What it demonstrates |
|
||||
|--------|----------------------|
|
||||
| `classic_fcfs` | Basic execution with FCFS, no I/O |
|
||||
| `convoy_effect` | Convoy effect: one long process blocking many short ones |
|
||||
| `rr_demo` | Fair time-sharing with Round Robin (quantum=3) |
|
||||
| `starvation` | Low-priority processes never receive CPU |
|
||||
| `aging_fix` | The same starvation scenario, solved with aging |
|
||||
| `io_heavy` | Mix of CPU Bound vs. I/O Bound processes |
|
||||
| `multilevel_demo` | Multiple queues with different priorities |
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Tests
|
||||
|
||||
```bash
|
||||
# Run all unit tests
|
||||
npm test
|
||||
|
||||
# Watch mode (re-runs on save)
|
||||
npm run test:watch
|
||||
|
||||
# With coverage report
|
||||
npm run test:coverage
|
||||
```
|
||||
|
||||
Tests cover the simulation engine, all scheduling algorithms, and metrics computation.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|-----------|
|
||||
| UI Framework | React 18 |
|
||||
| Language | TypeScript 5 |
|
||||
| Build tool | Vite 6 |
|
||||
| Styling | Tailwind CSS 4 |
|
||||
| Global state | Zustand 5 |
|
||||
| Charts | Recharts |
|
||||
| Icons | Lucide React |
|
||||
| Testing | Vitest + Testing Library |
|
||||
|
||||
---
|
||||
|
||||
## 📄 Additional Documentation
|
||||
|
||||
- [📐 Scheduling Algorithms](./docs/algorithms.en.md) — detailed description of each algorithm, tie-breaking rules, and examples
|
||||
- [📏 Metrics](./docs/metrics.en.md) — formulas and definitions for all computed metrics
|
||||
- [📝 JOSS Paper](./paper.md) — scientific paper submitted to the Journal of Open Source Software
|
||||
|
||||
*Também disponível em: [🇧🇷 Português](./README.md)*
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
Contributions are welcome! Feel free to open an [issue](https://github.com/lucasrguerra/pss/issues) or submit a Pull Request.
|
||||
|
||||
---
|
||||
|
||||
## 📜 License
|
||||
|
||||
Distributed under the [MIT License](./LICENSE). Developed by [Lucas Rayan Guerra](https://github.com/lucasrguerra).
|
||||
@@ -7,7 +7,7 @@
|
||||
[](https://vitejs.dev/)
|
||||
[](https://tailwindcss.com/)
|
||||
[](https://vitest.dev/)
|
||||
[](https://opensource.org/licenses/ISC)
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
|
||||
---
|
||||
|
||||
@@ -189,6 +189,9 @@ Os testes cobrem a engine de simulação, todos os algoritmos de escalonamento,
|
||||
|
||||
- [📐 Algoritmos de Escalonamento](./docs/algorithms.md) — descrição detalhada de cada algoritmo, regras de desempate e exemplos
|
||||
- [📏 Métricas](./docs/metrics.md) — fórmulas e definições de todas as métricas calculadas
|
||||
- [📝 JOSS Paper](./paper.md) — artigo científico submetido ao Journal of Open Source Software
|
||||
|
||||
*Also available in: [🇺🇸 English](./README.en.md)*
|
||||
|
||||
---
|
||||
|
||||
@@ -200,4 +203,4 @@ Contribuições são bem-vindas! Sinta-se livre para abrir uma [issue](https://g
|
||||
|
||||
## 📜 Licença
|
||||
|
||||
Distribuído sob a [Licença ISC](./LICENSE). Desenvolvido por [Lucas Rayan Guerra](https://github.com/lucasrguerra).
|
||||
Distribuído sob a [Licença MIT](./LICENSE). Desenvolvido por [Lucas Rayan Guerra](https://github.com/lucasrguerra).
|
||||
@@ -0,0 +1,164 @@
|
||||
# Scheduling Algorithms
|
||||
|
||||
*Também disponível em: [🇧🇷 Português](./algorithms.md)*
|
||||
|
||||
This document describes in detail the scheduling algorithms implemented in PSS. For each algorithm, the operating principle, parameters, tie-breaking rules, and educational examples are presented.
|
||||
|
||||
---
|
||||
|
||||
## General Rules
|
||||
|
||||
- **Time unit:** the simulator operates in discrete *ticks*. Each tick represents 1 CPU time unit.
|
||||
- **Bursts:** each process has an alternating sequence of bursts: `CPU → I/O → CPU → ...`, always starting with CPU.
|
||||
- **Tie-breaking:** when two processes are tied on the algorithm's selection criterion, priority goes to the one that arrived first (`arrivalTime`). As a second tie-breaker, `id` is used in lexicographic order.
|
||||
- **Context Switch:** if configured (≥ 1 tick), an overhead is inserted every time the CPU switches processes.
|
||||
|
||||
---
|
||||
|
||||
## FCFS — First Come, First Served
|
||||
|
||||
**Type:** Non-preemptive
|
||||
|
||||
### How it works
|
||||
|
||||
Perhaps the most intuitive algorithm: the process that arrived first is served first. The Ready queue is sorted by `arrivalTime`. Once a process occupies the CPU, it stays there until its current CPU burst is complete — no interruptions.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
P1: arrival=0, CPU: 4 ticks
|
||||
P2: arrival=1, CPU: 3 ticks
|
||||
P3: arrival=2, CPU: 1 tick
|
||||
|
||||
Gantt: | P1 P1 P1 P1 | P2 P2 P2 | P3 |
|
||||
Tick: 0 1 2 3 4 5 6 7
|
||||
```
|
||||
|
||||
| Process | Turnaround | Waiting |
|
||||
|---------|:----------:|:-------:|
|
||||
| P1 | 4 | 0 |
|
||||
| P2 | 6 | 3 |
|
||||
| P3 | 6 | 5 |
|
||||
|
||||
### Note: Convoy Effect
|
||||
|
||||
If a long process arrives before several short ones, the short ones wait a long time — even though the CPU could be serving them. This phenomenon is called the **Convoy Effect** and is one of the main drawbacks of FCFS. Try the `convoy_effect` preset to visualize it.
|
||||
|
||||
---
|
||||
|
||||
## SJF — Shortest Job First (Non-Preemptive)
|
||||
|
||||
**Type:** Non-preemptive
|
||||
|
||||
### How it works
|
||||
|
||||
When selecting the next process, SJF chooses the one with the **shortest remaining CPU burst** in the Ready queue. Once on the CPU, the process is not interrupted until its burst is complete.
|
||||
|
||||
SJF is optimal for minimizing average waiting time, but has a practical drawback: in real systems, future burst durations are unknown. In the simulator, you define bursts explicitly, so SJF can be applied perfectly.
|
||||
|
||||
### Parameters
|
||||
|
||||
No additional parameters.
|
||||
|
||||
---
|
||||
|
||||
## SRTF — Shortest Remaining Time First (Preemptive SJF)
|
||||
|
||||
**Type:** Preemptive
|
||||
|
||||
### How it works
|
||||
|
||||
Preemptive version of SJF. At each tick, the scheduler checks whether any process in the Ready queue has a **shorter** remaining burst than the currently running process. If so, a preemption occurs: the current process is returned to the Ready queue, and the new candidate takes the CPU.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
P1: arrival=0, CPU: 8 ticks
|
||||
P2: arrival=1, CPU: 4 ticks
|
||||
|
||||
Tick 0: P1 starts (remaining=8)
|
||||
Tick 1: P2 arrives (remaining=4 < 7) → preemption!
|
||||
Tick 5: P2 finishes → P1 resumes (remaining=7)
|
||||
Tick 12: P1 finishes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Round Robin (RR)
|
||||
|
||||
**Type:** Preemptive
|
||||
**Parameter:** `quantum` (time slice, default: 2)
|
||||
|
||||
### How it works
|
||||
|
||||
The Ready queue is treated as a circular queue. Each process receives at most `quantum` consecutive CPU ticks. If the process still has remaining burst at the end of the quantum, it goes back to the **end** of the Ready queue and waits its turn.
|
||||
|
||||
I/O bursts **do not** consume quantum — the process voluntarily leaves the CPU when initiating I/O.
|
||||
|
||||
### Trade-off
|
||||
|
||||
The smaller the quantum, the fairer the time-sharing, but the higher the context switch overhead. The larger the quantum, the more RR behaves like FCFS.
|
||||
|
||||
---
|
||||
|
||||
## Priority Scheduling (Non-Preemptive and Preemptive)
|
||||
|
||||
**Type:** Non-preemptive or Preemptive (select in the panel)
|
||||
**Parameters:** Aging (optional) + aging interval
|
||||
|
||||
### How it works
|
||||
|
||||
Each process has a priority from `1` (highest) to `10` (lowest). The scheduler always selects the highest-priority process in the Ready queue.
|
||||
|
||||
- **Non-preemptive:** once on the CPU, the process completes its burst without interruption.
|
||||
- **Preemptive:** if a higher-priority process arrives, the current one is immediately preempted.
|
||||
|
||||
### Starvation and Aging
|
||||
|
||||
The classic problem with Priority Scheduling is **starvation**: low-priority processes may *never* receive the CPU if high-priority processes keep arriving.
|
||||
|
||||
The solution is **aging**: every `agingInterval` ticks a process spends in the Ready queue, its priority is incremented by 1 (i.e., the numeric value decreases), down to a minimum of `1`. Over time, even low-priority processes reach the head of the queue.
|
||||
|
||||
Try the `starvation` and `aging_fix` presets to see this difference.
|
||||
|
||||
---
|
||||
|
||||
## HRRN — Highest Response Ratio Next
|
||||
|
||||
**Type:** Non-preemptive
|
||||
|
||||
### How it works
|
||||
|
||||
HRRN tries to be fairer than SJF by taking the process's waiting time into account. At each selection, the **Response Ratio** of each process in the Ready queue is computed:
|
||||
|
||||
```
|
||||
ratio = (waitingTime + burstTime) / burstTime
|
||||
```
|
||||
|
||||
The process with the **highest ratio** is selected. This naturally increases the priority of processes that have been waiting a long time, preventing starvation.
|
||||
|
||||
| Situation | Effect on ratio |
|
||||
|-----------|----------------|
|
||||
| Process with short burst | high ratio from the start |
|
||||
| Process that has been waiting a long time | ratio grows over time |
|
||||
| Process with long burst + little wait | low ratio |
|
||||
|
||||
---
|
||||
|
||||
## Multilevel Queue
|
||||
|
||||
**Type:** Preemptive
|
||||
**Parameters:** number of queues, quantum per queue
|
||||
|
||||
### How it works
|
||||
|
||||
Processes are distributed across multiple queues with different priorities. Each queue has its own Round Robin quantum. Higher-priority queues are always served first — a lower-priority queue only receives CPU if all queues above it are empty.
|
||||
|
||||
This allows different classes of processes to be treated distinctly: for example, interactive processes in high-priority queues (small quantum) and batch processes in low-priority queues (larger quantum).
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- Silberschatz, A., Galvin, P. B., & Gagne, G. — *Operating System Concepts*, 10th edition
|
||||
- Tanenbaum, A. S. — *Modern Operating Systems*, 4th edition
|
||||
@@ -1,5 +1,7 @@
|
||||
# 📐 Algoritmos de Escalonamento
|
||||
|
||||
*Also available in: [🇺🇸 English](./algorithms.en.md)*
|
||||
|
||||
Este documento descreve em detalhes os algoritmos de escalonamento implementados no PSS. Para cada algoritmo são apresentados o princípio de funcionamento, parâmetros, regras de desempate e exemplos didáticos.
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,116 @@
|
||||
# Metrics
|
||||
|
||||
*Também disponível em: [🇧🇷 Português](./metrics.md)*
|
||||
|
||||
PSS automatically computes a set of metrics at the end (or during) the simulation. This document explains each metric, its formula, what it represents, and how to read it in the charts.
|
||||
|
||||
---
|
||||
|
||||
## Per-Process Metrics
|
||||
|
||||
These metrics are computed individually for each simulated process.
|
||||
|
||||
| Metric | Formula | What it means |
|
||||
|--------|---------|----------------|
|
||||
| **Arrival Time** | `arrivalTime` | Tick at which the process first entered the Ready queue |
|
||||
| **First CPU Tick** | `startTick` | Tick at which the process first used the CPU |
|
||||
| **Finish Time** | `finishTick` | Tick at which the process completed its execution |
|
||||
| **Response Time** | `startTick − arrivalTime` | How long the process waited before receiving the CPU for the first time |
|
||||
| **Turnaround Time** | `finishTick − arrivalTime` | Total lifetime of the process (arrival → completion) |
|
||||
| **Waiting Time** | `turnaround − cpuTime − ioTime` | Total time spent in the Ready queue (doing nothing useful) |
|
||||
| **CPU Time** | Σ ticks in Running state | Total CPU actually consumed |
|
||||
| **I/O Time** | Σ ticks in Waiting state | Total time waiting for I/O devices |
|
||||
| **CPU Utilization** | `cpuTime / turnaround × 100` | Percentage of the turnaround time the process was actually using the CPU |
|
||||
| **Bound Type** | see below | Classification of the process as CPU Bound, I/O Bound, or Balanced |
|
||||
|
||||
### Table visualization
|
||||
|
||||
In the **Per Process** tab, each row displays inline horizontal mini progress bars next to the numeric values. The bars are proportional to the **largest value of the same metric among all processes**, enabling immediate visual comparison:
|
||||
|
||||
| Column | Bar color |
|
||||
|--------|-----------|
|
||||
| Response Time | Amber |
|
||||
| Turnaround Time | Blue |
|
||||
| Waiting Time | Orange |
|
||||
| CPU Time | Emerald |
|
||||
| I/O Time | Cyan |
|
||||
| CPU Utilization | Violet → Blue gradient |
|
||||
|
||||
---
|
||||
|
||||
## Global Metrics
|
||||
|
||||
Computed over the complete set of processes in the simulation.
|
||||
|
||||
| Metric | Formula |
|
||||
|--------|---------|
|
||||
| **Avg Response Time** | Average of all processes' response times |
|
||||
| **Avg Turnaround Time** | Average of all turnaround times |
|
||||
| **Avg Waiting Time** | Average of all waiting times |
|
||||
| **CPU Throughput** | `completed processes / total simulation time` |
|
||||
| **CPU Utilization (global)** | `Σ Running ticks / total time × 100` |
|
||||
| **Total Simulation Time** | Tick of the last completion event |
|
||||
|
||||
In the **Global** tab, each time card (Response, Turnaround, Waiting) displays a bar proportional to the **total simulation time**, indicating "how much of that total time the average process spends in that state". The CPU Utilization bar uses an amber → green gradient to indicate utilization health.
|
||||
|
||||
---
|
||||
|
||||
## CPU Bound vs. I/O Bound Classification
|
||||
|
||||
At the end of the simulation, each process is automatically classified based on the proportion of time spent on CPU and I/O:
|
||||
|
||||
```
|
||||
cpuRatio = cpuTime / (cpuTime + ioTime)
|
||||
ioRatio = ioTime / (cpuTime + ioTime)
|
||||
|
||||
cpuRatio ≥ 0.65 → CPU Bound
|
||||
ioRatio ≥ 0.65 → I/O Bound
|
||||
otherwise → Balanced
|
||||
```
|
||||
|
||||
- **CPU Bound:** the process spends most of its time using the processor.
|
||||
- **I/O Bound:** the process spends most of its time waiting for I/O devices.
|
||||
- **Balanced:** the process uses CPU and I/O in a balanced way.
|
||||
|
||||
> **In the process list:** estimate computed from the declared bursts (before simulation).
|
||||
> **In the metrics table:** classification computed from the actual recorded times.
|
||||
|
||||
---
|
||||
|
||||
## Charts ("Chart" tab)
|
||||
|
||||
### Comparative Profile — Radar Chart
|
||||
|
||||
Displayed when there are **2 or more processes**. Each axis represents a time dimension, normalized from 0–100% relative to the largest value in that dimension among all processes:
|
||||
|
||||
| Axis | Meaning |
|
||||
|------|---------|
|
||||
| **Turnaround** | Relative total lifetime |
|
||||
| **Response** | Relative time to first CPU |
|
||||
| **Waiting** | Relative time in the Ready queue |
|
||||
| **CPU Time** | Relative CPU usage |
|
||||
| **I/O Time** | Relative I/O usage |
|
||||
|
||||
Each process is drawn as a colored polygon (the color configured for the process). Wider polygons indicate processes with larger times in the corresponding dimensions. The radar chart is ideal for identifying **profile differences** between processes — for example, a CPU Bound process will have a much larger CPU Time axis than I/O Time.
|
||||
|
||||
### Per-Process Breakdown — Stacked Bar Chart
|
||||
|
||||
Always displayed. Each bar represents a process, with stacked segments:
|
||||
|
||||
- **Amber** — Waiting Time
|
||||
- **Green** — CPU Time
|
||||
- **Cyan** — I/O Time
|
||||
|
||||
The total height of each bar equals the **Turnaround Time** of the process.
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
Consider three processes with the following bursts:
|
||||
|
||||
| Process | Bursts | cpuTime | ioTime | cpuRatio | Classification |
|
||||
|---------|--------|:-------:|:------:|:--------:|:--------------:|
|
||||
| P1 | CPU:8, IO:1, CPU:1 | 9 | 1 | 90% | CPU Bound |
|
||||
| P2 | CPU:1, IO:8, CPU:1 | 2 | 8 | 20% | I/O Bound |
|
||||
| P3 | CPU:4, IO:2, CPU:4 | 8 | 2 | 80% | CPU Bound |
|
||||
@@ -1,5 +1,7 @@
|
||||
# 📏 Métricas
|
||||
|
||||
*Also available in: [🇺🇸 English](./metrics.en.md)*
|
||||
|
||||
O PSS calcula automaticamente um conjunto de métricas ao final (ou durante) a simulação. Este documento explica cada métrica, sua fórmula, o que ela representa e como lê-la nos gráficos.
|
||||
|
||||
---
|
||||
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "pss",
|
||||
"version": "1.0.0",
|
||||
"version": "1.1.0",
|
||||
"description": "O Process Scheduler Simulator é uma ferramenta educacional interativa que roda inteiramente no navegador",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
@@ -43,7 +43,7 @@
|
||||
},
|
||||
"keywords": [],
|
||||
"author": "Lucas Rayan Guerra",
|
||||
"license": "ISC",
|
||||
"license": "MIT",
|
||||
"type": "commonjs",
|
||||
"bugs": {
|
||||
"url": "https://github.com/lucasrguerra/pss/issues"
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: 'PSS: A Browser-Based Interactive Simulator for CPU Scheduling Algorithms'
|
||||
tags:
|
||||
- operating systems
|
||||
- CPU scheduling
|
||||
- process scheduling
|
||||
- computer science education
|
||||
- simulation
|
||||
- visualization
|
||||
- TypeScript
|
||||
- React
|
||||
authors:
|
||||
- name: Lucas Rayan Guerra
|
||||
orcid: 0009-0002-3170-4126
|
||||
affiliation: 1
|
||||
email: lucas.guerra@ufrpe.br
|
||||
affiliations:
|
||||
- name: Universidade Federal Rural de Pernambuco (UFRPE), Brazil
|
||||
index: 1
|
||||
date: 23 March 2026
|
||||
bibliography: references.bib
|
||||
---
|
||||
|
||||
# Summary
|
||||
|
||||
The **Process Scheduler Simulator (PSS)** is an open-source, browser-based interactive tool designed to help students, instructors, and practitioners understand and compare classical CPU scheduling algorithms from the field of Operating Systems (OS). PSS runs entirely client-side — no server, no installation — making it instantly accessible via any modern web browser at [https://pss.lucasrguerra.dev.br](https://pss.lucasrguerra.dev.br).
|
||||
|
||||
Users define a set of processes, each with an arbitrary sequence of alternating CPU and I/O bursts, and select one of eight scheduling algorithms. The simulator then executes the schedule tick by tick, rendering a live Gantt chart and computing a comprehensive set of performance metrics for each process and for the simulation as a whole. PSS supports First Come First Served (FCFS), Shortest Job First (SJF), Shortest Remaining Time First (SRTF), Round Robin (RR), non-preemptive and preemptive Priority Scheduling (with optional aging), Highest Response Ratio Next (HRRN), and Multilevel Queue scheduling.
|
||||
|
||||
# Statement of Need
|
||||
|
||||
CPU scheduling is a foundational topic in Operating Systems curricula worldwide. However, the subject is widely known to be challenging for students to grasp through lecture and textbook alone: algorithms such as SRTF, aging-based Priority Scheduling, and Multilevel Queue involve complex, time-dependent state transitions that are difficult to internalize from a static Gantt diagram drawn on a blackboard.
|
||||
|
||||
Existing textbooks [@silberschatz2018; @tanenbaum2015] include static examples and exercises, but provide no means for students to interactively explore edge cases, compare algorithms, or observe emergent phenomena such as the convoy effect or starvation in real time. Laboratory environments that require OS installation or command-line configuration create friction that discourages experimentation, particularly for students in resource-constrained settings.
|
||||
|
||||
PSS addresses this gap by providing a zero-installation, zero-configuration simulation environment that runs directly in the browser. The target audience includes:
|
||||
|
||||
- **Students** in introductory and intermediate Operating Systems courses who want to visualize abstract algorithm behavior;
|
||||
- **Instructors** seeking a live, configurable demonstration tool for classroom or remote teaching;
|
||||
- **Researchers and practitioners** who need a quick, reproducible environment to illustrate scheduling concepts.
|
||||
|
||||
The configurable parameters — quantum for Round Robin, aging interval and threshold for Priority Scheduling, and per-queue quantum for Multilevel — enable learners to observe how parameter choices affect fairness, throughput, and starvation, all within a single interactive session.
|
||||
|
||||
# State of the Field
|
||||
|
||||
Several browser-based and desktop scheduling simulators exist. OS-sim [@ossim] offers a graphical simulation of a full operating system, including scheduling, but targets upper-division students and requires local installation. The CPU Scheduling Simulator by Mitchell [@mitchelljava] is a Java desktop application that covers a subset of algorithms without I/O burst modeling. Web-based tools such as Process Scheduling Simulator by Nikhil Anand cover FCFS, SJF, and RR, but do not support aging, HRRN, or Multilevel Queue, and lack composable I/O burst sequences.
|
||||
|
||||
PSS distinguishes itself in three key ways. First, it models **full CPU-I/O burst sequences** for each process, rather than a single CPU burst, enabling simulation of realistic workloads and the CPU Bound vs. I/O Bound classification. Second, it implements a broader set of algorithms — including HRRN and Multilevel Queue with per-queue quantum — than most comparable tools. Third, the entire application is deployed as a **static single-page application** with no backend dependency, enabling one-click access and offline use via Docker, which lowers the barrier for classroom adoption.
|
||||
|
||||
# Software Design
|
||||
|
||||
PSS is built with React 18 [@react] and TypeScript 5, bundled with Vite 6, and styled with Tailwind CSS 4. The architecture enforces a strict separation between the **simulation core** and the **presentation layer**.
|
||||
|
||||
The `src/core/` directory contains pure TypeScript modules with no React dependency: `engine.ts` orchestrates the simulation loop on a tick-by-tick basis, `algorithms/` implements each scheduling algorithm as a subclass of an abstract `BaseScheduler`, and `metrics.ts` computes all per-process and global metrics from the recorded state history. This separation ensures that the core logic is independently testable and reusable outside the browser context.
|
||||
|
||||
The React layer delegates all state mutations to a Zustand 5 store, which acts as a single source of truth for the process list, scheduler configuration, simulation state, and computed metrics. Components are purely presentational: they read from the store and dispatch actions, never computing scheduling logic directly.
|
||||
|
||||
This architecture was chosen to maximize testability: the `src/core/` package is covered by Vitest unit tests that verify algorithm correctness against hand-crafted Gantt chart expectations and metric values. The current test suite covers all eight scheduling algorithms, the simulation engine, and the metrics module, reaching 100% statement coverage of the core layer.
|
||||
|
||||
The Gantt chart is rendered as a custom React component with SVG-free CSS layout, enabling smooth 60 fps animation at playback speeds ranging from 0.25× to 4×. Charts in the metrics panel (radar chart for comparative process profiles, stacked bar chart for time breakdown) are rendered with Recharts [@recharts].
|
||||
|
||||
# Research Impact Statement
|
||||
|
||||
PSS was developed as part of the Computer Science undergraduate program at the Universidade Federal Rural de Pernambuco (UFRPE, Brazil). The tool has been used in the Operating Systems course at UFRPE to supplement lectures on CPU scheduling, providing students with a hands-on environment to experiment with algorithm parameters and verify their understanding of course material.
|
||||
|
||||
The availability of PSS as a fully open-source project under the MIT license, with Docker and `npm run dev` deployment paths, enables any institution to adopt or adapt the simulator without cost or proprietary dependency. The live deployment at [https://pss.lucasrguerra.dev.br](https://pss.lucasrguerra.dev.br) provides a stable public URL suitable for sharing in syllabi, assignments, and online course materials.
|
||||
|
||||
The built-in preset scenarios — including `convoy_effect`, `starvation`, and `aging_fix` — provide reproducible, named examples of classical OS phenomena that instructors can reference directly in lectures, assignments, or exam questions, facilitating standardized discussion of algorithm trade-offs.
|
||||
|
||||
# AI Usage Disclosure
|
||||
|
||||
The author used AI-assisted coding tools (GitHub Copilot and Google Gemini) during development for code completion, documentation drafting, and test generation. All AI-generated content was reviewed, tested, and verified by the author before inclusion in the repository. The core scheduling algorithms were validated against hand-computed examples from [@silberschatz2018] and [@tanenbaum2015].
|
||||
|
||||
# Acknowledgements
|
||||
|
||||
The author thanks the professors and students of the Operating Systems course at UFRPE whose feedback shaped the features and usability of PSS.
|
||||
|
||||
# References
|
||||
@@ -0,0 +1,48 @@
|
||||
@book{silberschatz2018,
|
||||
author = {Silberschatz, Abraham and Galvin, Peter Baer and Gagne, Greg},
|
||||
title = {Operating System Concepts},
|
||||
edition = {10th},
|
||||
publisher = {Wiley},
|
||||
year = {2018},
|
||||
isbn = {978-1-119-32091-3}
|
||||
}
|
||||
|
||||
@book{tanenbaum2015,
|
||||
author = {Tanenbaum, Andrew S. and Bos, Herbert},
|
||||
title = {Modern Operating Systems},
|
||||
edition = {4th},
|
||||
publisher = {Pearson},
|
||||
year = {2015},
|
||||
isbn = {978-0-13-359162-0}
|
||||
}
|
||||
|
||||
@misc{react,
|
||||
author = {{Meta Platforms, Inc.}},
|
||||
title = {React: The library for web and native user interfaces},
|
||||
year = {2024},
|
||||
howpublished = {\url{https://react.dev}},
|
||||
note = {Version 18}
|
||||
}
|
||||
|
||||
@misc{recharts,
|
||||
author = {{Recharts Group}},
|
||||
title = {Recharts: Redefined chart library built with React and D3},
|
||||
year = {2024},
|
||||
howpublished = {\url{https://recharts.org}},
|
||||
note = {Version 3}
|
||||
}
|
||||
|
||||
@misc{ossim,
|
||||
author = {Robbins, Kay A.},
|
||||
title = {{OS-sim}: A Graphical, Interprocess Operating System Simulator},
|
||||
year = {2012},
|
||||
howpublished = {\url{https://github.com/mayank-02/multithreading-library}},
|
||||
note = {Used in OS coursework at several universities}
|
||||
}
|
||||
|
||||
@misc{mitchelljava,
|
||||
author = {Mitchell, Michael},
|
||||
title = {{CPU Scheduling Simulator}: A Java-based desktop scheduling simulator},
|
||||
year = {2017},
|
||||
howpublished = {\url{https://github.com/MichaelMitchell/CPU-Scheduler-Simulator}}
|
||||
}
|
||||
Reference in new issue
Block a user