Simulation only. This page runs a JavaScript port of the project's C++ simulation core in your browser. No file is transferred, no socket is opened and no server is contacted; all figures describe synthetic workloads, not measurements of a deployed system.

1 · Workload and parameters

Pick a workload, set the server parameters, then run one or more schedulers on exactly the same input.

Applied by the Round Robin scheduler only.

Charged to every slice handed to a worker.

2 · Scheduler comparison

Every scheduler below processed the same requests, threads, quantum and overhead. Best value per column is highlighted; “dispatches” counts how many slices were handed to workers.

Scheduler Avg waiting (s) Avg turnaround (s) Avg response (s) Throughput (req/s) Fairness (Jain) Makespan (s) Dispatches
Average waiting time (lower is better)
Average turnaround time (lower is better)
Throughput (higher is better)
Jain fairness index over client throughput (1.0 = equal)

3 · Worker timeline

One row per worker thread. Each block is a slice the scheduler handed to that worker; colour identifies the client. Use the controls to observe when requests are dispatched, how long they wait and how work interleaves.

t = 0.000 s

4 · Per-request results and per-client view

Columns match the CSV written by the command-line version.

Requests

ID client arrival start finish waiting turnaround response thread

Per-client throughput

client requests data (MB) active span (s) MB/s

Worker utilisation

threadbusy (s)utilisation

5 · What this demo is, and what it is not

Model

  • Discrete-event simulation: time advances from event to event, not in fixed ticks.
  • A server owns a fixed number of worker threads; each worker serves one slice at a time.
  • A slice takes remaining_size / bandwidth simulated seconds plus a configurable per-dispatch overhead.
  • Round Robin caps a slice at the quantum; unfinished requests re-enter the queue.
  • WFQ-like uses a priority-derived weight and virtual finish tags; it is a simplified approximation, not a byte-accurate implementation of weighted fair queueing.

Honest scope

  • No real transfer, sockets, threads or disk I/O are involved; the numbers are properties of the model.
  • Bandwidth values are inputs from the workload file, not measured link speeds.
  • Metrics characterise the synthetic workloads shipped with the project and the parameter ranges reachable in this UI. They are not benchmark results from a deployed server.
  • Workloads marked “C++ CLI” were produced by ./simulator --generate-sample … --n N --seed S; the boundary workload is hand-authored to exercise ties and limit cases.
  • The browser-side generator uses a small local PRNG and is labelled accordingly; it does not reproduce the CLI's std::mt19937 sequence. Use the bundled CLI datasets for exact reproduction.
  • No analytics, no cookies and no requests to third parties: every asset is served from this repository.
Equivalence with the command-line simulator

The JavaScript core (engine.js) mirrors the C++ modules scheduler, simulation_engine and metrics operation by operation, including the heap procedures used by the C++ standard library implementation and the tie-breaking rules among equal keys. Across 12 reference configurations and all five schedulers the port reproduces 2455 per-request rows and 60 summary rows of the command-line output; the largest deviation observed is 4.99e-5, inside the four-decimal rounding of the CSV the CLI writes. You can re-run the whole comparison yourself on the equivalence check page: it replays those twelve workloads in your browser against the CSV files recorded from the command-line simulator, which are stored as plain text in oracle_bundle.js.